|
|
|
 |
 |
|
Written by Dr. Andrew Makar
|
In the previous article, I shared a couple of key lessons learned in team development using Bruce Tuckman’s model of Forming, Storming, Norming and Performing. Every team goes through these four phases regardless if the team recognizes it or not. If the team can apply the lessons learned in the forming and storming phase, the team progress faster to the norming and performing phase. In this second article, I’ll highlight a few useful lessons learned across the Norming and Performing phases.
Lesson Learned: Identity and communicate expectations in the Norming phase
Its difficult to achieve the Norming phase, if the team doesn’t communicate or share expectations for team norms. One method for communicating, discussing and achieving team norms is to host a kick off meeting with the immediate team and share how status reports will be collected, the cadence of key meetings and how teams should work together. By communicating expectations, the team can agree on working practices.
In one of my projects, the entire team was all located within the team room. The team room had a speaker phone for conference calls. Some of the team members would use the speaker phone for all their calls and despite having the team located in one room, the speaker phone created a distraction for others. The issue was fixed by reserving separate break out rooms for the team members and the speaker phone was reserved for meetings with all the team members.
Another example involved reporting milestone with the standard “traffic light” approach - red, yellow and green for key milestones. Green was used to identify on-track milestones, yellow for at-risk and red for late tasks. The business customer was used to using blue for on target, green for complete and red for late. After using the original traffic light status reporting, the team had to switch to accommodate the business customer’s expectations and own standards.
Team norms are often established in the forming phase although it may take several iterations to work out the “kinks”. In the status reporting example, it took a few times to produce the status reports before the team understood the revised formatting and cadence. You may find this experience when you conduct your first issue review meeting or your first program status meeting. By establishing norms early, communicating them and adjusting norms based on team feedback, the team will achieve the norming phase much faster.
Lesson Learned: Identify and save best practices found in the Performing phase
In the Performing phase, the team establishes a rhythm for managing issues, responding to problems and executing work. Status reports are submitted on time, action items are appropriately tracked and roles are understood. It may take several weeks to reach the performing phase and during this time, the team has likely created several best practices and expected team norms.
You don’t have to wait for a lessons learned session at the end of the project to identify and discuss the best practices. As the team experiences best practices that work well for the team, make a note of them and save them for expected norms for the next project and team formation.
One best practice my team established early on was the use of a daily stand-up meeting for all the team leads. When the stand-ups were first conducted, they lacked structure and the team continued to ramble. The team adjusted the practice of their stand-up meeting so each team member would highlight what they are working on and the top issues they were experiencing. The work to resolve the team member’s issue and further coordination would happen outside the meeting.
These types of best practices can be documented in a single MS-PowerPoint slide and incorporated a kick off deck for future project teams. Each slide can be removed or adjusted based on the project need and expected team norms.
Form , Storm, Norm, Perform - Repeat
Programs can be long term projects depending on the size and scope. In a two to five year project or program, team members will fade in and out and as new team members are introduced and the natural phases of forming, norming and storming will happen again and again. The key is to recognize the importance of these phases, embrace them and manage the issues as the team works on their projects. Team development will inevitably have conflict and differences in opinion are healthy for team development. Establishing norms is important for teams to achieve the desired performance.
So go ahead and start forming and storming. Achieve norming and start performing. We’ve got projects to deliver.
|
|
|
|
|
|
Written by Dr. Andrew Makar
|
As project managers, we are all familiar with Bruce Tuckman’s team development model and the phases of forming, storming, norming and performing. You may not realize you’re going through Tuckman’s model when a team first forms, but understanding the stages helps rationalize the initial politeness, eventual conflict, stress relieving agreement and realized fluid team performance that all teams undergo. It is a natural cycle of team development that everyone experiences even if you haven’t been through a formal organizational behavior course. Team can struggle in each of the various stages and this article shares a couple of key lessons learned as they formed, stormed, normed and performed.
Lesson Learned: Build rapport during the Forming phase
The forming phase of the project team is the “feel good” stage of the team development where each person learns about the team members and first impressions are made. It is an easy stage to start out in because no one wants to raise any conflict or threaten specific authority. Of course not much gets done in this team formation phase but it is important to recognize the need for team formation.
My goal in the forming phase is to develop rapport with each of the team members. Learn some interesting facts or personal information that may uncover a common bond. Project schedules and status reports may help manage projects but relationships deliver projects. By building rapport quickly with your team members, you can leverage those common connections when the storming phase begins.
The forming phase can include a variety of structured and unstructured events ranging from getting coffee, going to lunch or hosting a dinner outside the office. It doesn’t need to be a lavish event although those types of events are fun to attend too. A few years ago, my director personally bought the entire army of consultants and employees Detroit Tiger tickets for a local home game. That night forty people attended a game, had a great time and build rapport with each other. This was an extremely generous and personal investment in the project. When I asked why she bought the entire group tickets, she simply said “It had to be done”.
You don’t have to do something as extravagant but I think you get the idea.
Lesson Learned: Accept and embrace the Storming phase
Storming inevitably happens so you might as well as dive right in and get it over with during this time period. As the project team begins to execute and form different opinions, the team will experience conflict. Role confusion, boundary definition and working in a company’s political hierarchy can all contribute to conflict and frustration in the Storming phase. Storming will inevitably happen so you might as well as embrace it and have a plan to respond to conflict with your team members.
My plan is simple. When conflict arises, find the appropriate time to address it one on one with the individual. As a project manager, you need to treat a disagreement or stress between two team members as an issue and simply acknowledge it. By stating the issue and acknowledging it with the team members, you can safely express your concern and both seek a resolution. Addressing conflict can be uncomfortable but remember it isn’t personal - it is a project issue.
Ironically, I’ve found by going through the storming phase and experiencing conflict, I’ve actually developed stronger rapport with the individual and improved the relationship. Some of my strongest relationships with team members resulted from a clear disagreement that was respectfully acknowledged and resolved. If you ignore the issue and think it will go away, storming will only continue in hinder team performance.
Resources for Forming and Storming
If you know teams are going to form and storm, it always helps to have a few resources help you get through the challenges. Below are a few recommended books on building rapport and effective conflict resolution
In my next article, I’ll explore a few more lessons learned as we continue across Tuckman’s team development model.
|
|
|
|
|
Written by Dr. Andrew Makar
|
The Request for Proposal (RFP) process is a purchasing process used to elicit service provider proposals for a specific product, service or solution. In Information Technology, this often translates into the purchasing of IT services, software or the combination of both. If you have ever been through an RFP purchasing cycle, then you know managing the RFP process can be a project in itself. In enterprise IT organizations, an RFP can be worth millions of dollars to a supplier and represent a strategic effort for both business and IT organizations.
Organizations want to know they are getting the best solution for their dollar and suppliers want to compete fairly for the business. Price isnt’ always the deciding factor in an RFP and the following five tips can be applied to improve the overall proposal process and ultimately the decision.
RFP Tip #1: Define the evaluation criteria upfront
A lot of effort is placed in defining the goals, scope and project details in a request for proposal package. There can be a lot of pressure to issue the RFP, make a decision and get started with the project in an effort do deliver business value quickly. However, project managers should take the time to define the evaluation criteria so both the selection team and suppliers understand all the areas that will be evaluated.
It is also important to share the evaluation criteria with the suppliers so the suppliers understand how the response will be evaluated. The project manager doesn’t need to share the criteria weighting, but it is helpful to let a supplier know the critieria. If project managers don’t include the criteria, a supplier may provide an inaccurate response and overstate one aspect of the proposal while understating another area. When suppliers receive feedback on the RFP decision, they may feel like they’ve missed an opportunity to highlight the benefits of their solution had they know the criteria earlier.
RFP Tip #2: Include a cross functional section of RFP reviewers
In a RFP process, the decision makers need to include more than just the business lead and the project manager. It is important to include a cross functional set of reviewers from purchasing, IT, the functional business organization, finance and legal. By engaging a cross functional team, you will get greater input into the price, contract and financial issues associated with the purchase decision. As IT managers, we are often challenged to move quickly, however, no one wants to spend more than they need to deliver IT services and each party wants to ensure the contractual and legal obligations are understood. By including a cross functional team, you’ll have appropriate representation to handle issues and concerns that can affect the entire organization.
RFP Tip #3: Conduct reference calls and site visits
Reference calls are an eye-opening experience. As you narrow down the prospective suppliers, remember to ask for customer reference calls. It is important to get candid and honest feedback from other organizations that have used the potential supplier’s products or services. The prospective supplier will be more than happy to provide client references and any other information needed to make an informed decision. The supplier should not attend the call so you can have an objective, open and honest dialogue. I’ve found by conducting customer reference calls, additional risks and lessons learned were quickly identified and could be applied to my own project.
If required, ask for a site visit to learn how the supplier has implemented a specific product or service. During one RFP outsourcing project, I travelled to several sites to understand how their technology was implemented as well as how the business used the solution and services. It is another opportunity to understand how a customer is living with the solution.
RFP Tip #4: Send all requests for communication to 1 person during the RFP process
With potentially millions of dollars in sales on the line, project managers and other members of the selection committee will often get calls for status, updates and any information to indicate a decision. Purchasing organizations usually have strict guidelines on communication with suppliers during a RFP selection process. It is best to send any and all requests for RFP questions to 1 person (usually a purchasing representative) authorized to provide status. In IT, relationships with your software and solution providers are critical and even though its “just business”, you want to ensure each supplier is treated fairly in the process. Information leaks can also damage the negotiation process.
RFP Tip #5: Incorporate promises made in the sales presentation into the contract
Suppliers will usually present their solution to the RFP selection committee. During these presentations, additional discussions and commitments may be made. If additional commitments or promises are offered during the presentation, make sure these commitments are translated into the written contract. Even if a commitment was made in a sales presentation, if it isn’t incorporated into the contract, it was never really a commitment.
Working on projects that leverage suppliers and external solutions are exciting projects. The RFP process provides the project manager with a new challenge that isn’t always found in internal systems development. If you get the opportunity to participate in an RFP, remember to treat it like its own “mini-project” as the issues, risks and timeline all needs to be managed.
|
|
|
|
|
Written by Dr. Andrew Makar
|
|
How do you ensure you’ve built a quality Microsoft Project Schedule?
Over time, we develop our own set of criteria for what makes a “good schedule” by combining real-world practice with project scheduling theory. One challenge with assessing project schedule quality is subjective nature of the evaluation as it always isn’t consistent across a project portfolio, department or company. A project manager may feel comfortable managing a high level schedule and another project manager may want the schedule defined in greater granularity (40-80 hours). Organizations need consistent advice and guidance based on best practices. Even if your organization has the old sage resident expert or a innovative PMO wunderkind, a coach can only review a fixed number of schedules at a given time.
I recently started working with a tool eliminates the bottleneck and not only analyzes your project schedule for quality but also provides coaching guidance on how to improve the project schedule. Steelray’s Project Analyzer is a powerful tool that can analyze a project schedule and provide detailed evaluation reports in seconds. The tool provides over 40 formulas and rules to assess the quality of your project schedule with literally one click of a button (Figure 1).
Figure 1 - Steelray Project Analyer
Using a traffic light status scorecard, Project Analyzer easily identifies problem areas in your schedule ranging from common schedule mistakes to complex quality assessments. Common scheduling errors like missing baseline data or missing assigned resources are visually flagged along with complex quality errors such as excessive slack durations, out of sequence tasks or poorly formed dependencies. The scorecard is customizable so you can quickly assess a schedule based on your organization’s schedule quality needs (Figure 2).
Figure 2 - Scorecard
The tool also filter’s the Microsoft Project schedule to identify the problem tasks for faster resolution. I’ve previously written about how to customize Microsoft Project to use custom filters to identify late tasks, but SteelRay Project Analyzer takes this concept to an entirely new level. The ability to quickly assess problems in a project schedule saves project managers time and reduces the administrative burden incurred during project execution.
Project Analyzer also provides coaching advice for each of the problem areas. By clicking on the whistle icon, the coaching panel appears and explains each schedule quality rule. More importantly, it tells the project manager what to do next to fix the problems in the project schedule (Figure 3).
Figure 3 - What is This and What Do I Do Next
I really like how the tool provides an objective assessment of the schedule, quickly identifies the tasks that need to be fixed and provides guidance on next steps to fix problem areas. It is even more impressive that all this analysis can be done in less than a minute. The project manager still needs to consider the context of the project and the subjective influences in the project schedule. In one example, the tool evaluates the project schedule for earned value management. If your organization hasn't adopted earned value, then this rule will not have much value to you. You can customize the scorecard to use the rules that apply to your organization. I also like how it assess criteria such as schedule performance index (SPI) and cost performance index (CPI) as it provides project managers with goals to achieve.
How can a PM, PMO or a solution provide use the tool?
The obvious application is to apply Project Analyzer to your own project schedules. As much as I pride myself on being able to schedule effectively in Microsoft Project, I found several problem areas within my schedules within seconds. You may think you’ve thought of everything when building a schedule and the tool provides a sanity check. The coaching feature also helps explain the rationale and future pitfalls if the scheduling issues are not resolved.
If you are a PMO manager responsible for provide coaching and counseling on project management processes, techniques and standards, this is a must have tool. A PMO team in a large organization can easily support hundreds of projects each year. Each PMO member may have their own interpretation and personal best practices on how to effectively develop and manage a project schedule. SteelRay’s Schedule Analyzer provides a consistent set of criteria across the entire organization and standardizes the guidance provided by PMO coaches.
If you manage projects that use 3rd party suppliers or offshore portions of the project to other teams, Project Analyzer will help you quickly assess the quality of the supplier schedules. Even if the project has fixed price deliverables with an outsourced supplier, conducting a quality assessment on the integrated schedule with both supplier and client tasks provides value to the project and supports risk management.
As a self-admitted IT geek, I love software tools that help you do work better. Finding useful and practical project management tools that help project managers plan and manage schedules better is encouraging for the project management profession. We need more tools like SteelRay that help us become better project managers not just through theory but through actual application. No single tool is a silver bullet for successful project management. You still need to apply your own rationale and logic to problems in your schedule. Download a free trial of SteelRay Project Analyzer and apply it to your own Microsoft project schedule.
|
|
|
|
|
Written by Dr. Andrew Makar
|
Rewarding a team member for a job well done or promoting an outstanding employee is easy. Counseling a poor performing employee, addressing a sensitive issue with a peer or trying to find a solution amongst two conflicting teams members is not. The reality is no matter how uncomfortable these conversations can be, we all can relate to being found in them. The outcome of the difficult conversation all depends on how you handle the discussion.
Instead of providing you with a generalized set of cliche guidelines for handling difficult conversations, we wanted to find some real-world situations and advice on how project managers in the field handled their difficult conversations. Ofcourse we changed the names and paraphrased a bit but as you read these examples, think about how you’d react and respond.
Situation #1: Poor Personal Skills
Joe was a knowledgeable employee who had strong technical skills who was often asked to be a guest speaker at technical conferences. Despite his technical strengths and contributions, he thought his compensation was low. Ofcourse, Joe apparently knew his pay was so low because he talked to his peers. Joe came into my office to address the issue. I gave him an honest evaluation of overall performance not just his technical ability.
Joe’s major issue was he had terrible interpersonal skills. Technically he was one of the stronger individuals on the team but his personal interactions actually hurt his performance. Being a technically astute, Joe often liked to demonstrate his technical expertise by criticizing other people’s ideas publicly. He thought he was helping by finding the optimal solution but those actions ended up alienating him from the team. Joe didn’t take the feedback well, got quite emotional and left work for the day. He eventually transferred to another department. Three years late, I ran into Joe and actually thanked me for having the courage to tell him the truth.
Joe needed a fresh start in a new team to build new relationships and try a more subtle approach to finding the right technical solution. He realized trying to outshine his co-workers with his technical expertise wasn’t helping his career or his reputation. He found by asking probing questions rather than putting down other people’s ideas, he was still recognized as a technical expert that people wanted to engage rather than avoid.
Key Lesson Learned: Tell the person the truth even if may hurt their feelings in the short term
Situation #2: Peer to Peer Combat
I had two employees who always differed in opinion and often verbally argued in front of the team. Both employees were seeking the best solution which they vocally defended. The constant fighting was disrupting the team. I brought both of the employees into the office and asked “Which one of you should I fire first?”. Both employees had important jobs but neither of them looked beyond their own objectives to see the big picture. Ironically, they both started defending the other indicating losing either of them would hurt the team. I also agreed them and the two agreed to prepare their own points of view and bring it to me for discussion. I also had them include ideas from the other point of view so they would see beyond their own ideas.
Key Lesson Learned: Help team members see the big picture and look beyond their own point of view.
Situation #3: About Last Night
Several team members got together after work and one employee had too much to drink and insulted a female employee with an inappropriate remark. One of the other employees contacted HR about the inappropriate behavior. HR wanted to fire the employee and I had a couple of days to resolve the situation. I discussed the situation and the employee admitted fault and indicated he apologized the the employee. I also spoke with the employee who reported the issue to HR and asked why he reported it if it wasn’t his business. I also spoke with the insulted employee and she was ok after the sincere apology.
HR still wanted to punish the employee with 2 week suspension with no pay. I didn’t agree with HR as what happens off the clock between adults is their business. HR continued to argue but fortunately, I had the final word.
Key Lesson Learned: Listen to all sides of the story, take personal situations into considerations and support your people.
Common Themes and Approaches
In all these examples, the managers faced difficult situations that required objectivity, honesty and respect for their team members. By showing respect for the other person, focusing on the desired outcome with emotion and avoiding the “Us versus Them” mentality, the managers were able to a have a difficult conversation. There is no guarantee the other person in the conversation won’t try to press you hot buttons or try to threaten, cry, shout or take make accusations, but by avoiding assumptions and applying these key lessons learned you can successful have difficult but meaningful conversations.
In preparing for a difficult conversation, it is helpful to ask yourself the following questions.
- What is the problem?
- What would does the other person think the problem is?
- What is the desired outcome?
- What's relationship do I have or want to have with the other person?
In several occasions, I even wrote out the answers rather the mentally reflect on them. You may also consider asking your counterpart to bring their own responses in preparation for the discussion.
Recommended Resources
Below are just a few recommended resources to help you prepare for difficult or crucial conversations. I’ve found them helpful in providing some guidance to handling those situations that are never defined in a project management book.
After all, no one said it was going to be easy.
Author's Note:
I first published this article on LiquidPlanner's blog - a leading online project management software company. They make great software that makes project management easier. Check them out!
|
|
|
|
|
<< Start < Prev 1 2 3 4 5 6 7 8 9 10 Next > End >>
|
|
Page 1 of 22 |
|
