Tactical PM Project Management Tips

Improving PM Efficiency Survey

andy@tacticalprojectmanagement.com (Dr. Andrew Makar) — Thu, 28 Feb 2013 15:31:31 GMT

Improving Project Management Efficiency Survey

What short cuts or tips to you apply to reduce project management administration?

Need Your Input: Lessons Learned with MS Project Survey

andy@tacticalprojectmanagement.com (Dr. Andrew Makar) — Tue, 08 May 2012 12:06:01 GMT

I'm working on a new presentation on Lessons Learned with Microsoft Project. I'd like to augment the presentation with your input.

Would you mind answering a 2 question survey?

More Team Development Lessons Learned

andy@tacticalprojectmanagement.com (Dr. Andrew Makar) — Tue, 05 Jul 2011 16:42:03 GMT

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.

Team Development Lessons Learned

andy@tacticalprojectmanagement.com (Dr. Andrew Makar) — Tue, 05 Jul 2011 16:39:05 GMT

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.

Five Steps to a Better Request for Proposal

andy@tacticalprojectmanagement.com (Dr. Andrew Makar) — Thu, 26 May 2011 15:27:02 GMT

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.

Build a Better Microsoft Project Schedule with Steelray Project Analyzer

andy@tacticalprojectmanagement.com (Dr. Andrew Makar) — Tue, 24 May 2011 19:12:41 GMT

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 3^rd 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.

Difficult Conversations: Real World Advice

andy@tacticalprojectmanagement.com (Dr. Andrew Makar) — Sat, 07 May 2011 14:01:59 GMT

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!

User Controlled Scheduling in MS Project 2010

andy@tacticalprojectmanagement.com (Dr. Andrew Makar) — Tue, 22 Mar 2011 03:30:19 GMT

With the MS Project 2010, project managers now have the option of scheduling tasks manually or letting MS Project schedule the task start and end dates using the scheduling engine. When I first head about this feature, I was convinced this is the dumbing down of project schedule development. However, I recognize a portion of MS Project users fall into the occasional project manager role versus the traditional professional project manager role. This article examines the features of user controlled scheduling and identifies some practical uses.

What is User Controlled Scheduling?

User controlled scheduling enables project managers to develop project schedules with or without the MS Project’s scheduling engine. In the manual scheduling mode, tasks can be entered with or without durations, start dates or end dates. Durations and dates are entered as free form text and summary tasks do not inherit dates and task data from sub-tasks (Figure 1).

Figure 1. User Controlled Scheduling in Excel

If sub-tasks are linked, the start and finish dates are not calculated unless the project manager chooses to enforce the links using the Respect Links button. From a user experience, the manual scheduling is much like planning a project in Microsoft Excel. This mode provides the flexibility to enter text-based values and document timing assumptions in the Start and Finish columns.

Project managers do have the option to switch between manually scheduled and automatically scheduled tasks. In the automatically scheduled tasks mode, the project engine kicks in and appropriately schedules the tasks based on the dependencies, calendars and resources assigned to the project. Fans of previous versions of MS Project will recognize the automatic scheduling mode as the familiar way of scheduling tasks in a project schedule.

When to use manual scheduling?

The application of manual scheduling is beneficial early in the project when high level target dates are known but the detailed tasks and timing are unknown. The idea of conducting top down planning versus the traditional bottom up planning provides greater flexibility in identifying summary ranges for a project timeline. Rolling wave planning would be applicable for future project phases that are not well defined. In practice, this feature seems feasible as portfolio planning for systems implementations is often conducted at the quarter or yearly basis.

For managers who fall into the “occasional” project manager category, the manual scheduling mode allows managers to use MS Project like a task list. Inexperienced MS Project users often complain about MS Project’s sudden date changes when changes are made to resource, duration or project dates. Manual scheduling avoids these concerns but the trade-off is the loss of benefits from the scheduling engine.

When project managers are conducting high level planning, the manual scheduling mode can be combined with the Timeline view in MS Project to create a phase level view of the project (Figure 2). These dates are only treated as high level dates as the supporting detail that determines if these dates are reasonable or not is missing.

Figure 2. Timeline View

The same view can be constructed using the automatic scheduling mode although project managers need to ensure they enter durations and dependencies correctly. With manual scheduling, the intent is to condcut a rough order magnitude of planning and later switch to automatic scheduling once specific task details are known.

My Recommendation

Maybe I’m too old-school in the ways of MS Project. I’ve been using it since 1994 and maybe too indoctrinated in the way the tool is designed to work with the scheduling engine. I liked the fact that my dates change when I adjust a duration and the dependent tasks adjust. I like the fact that MS Project looks at the resource availability, corporate holiday schedule and individual calendars to calculate realistic end dates. This is the way a scheduling engine is supposed to work.

However, in order to use the automatic mode, you need to understand the implications of adding resources and dependencies to develop a dynamic schedule. If your goal is to use MS Project as a task list without any date forecasting features, then manual scheduling will be a welcome addition. If you are an “occasional” project manager who needs to track high level dates and manage at the summary level, you’ll appreciate the new flexibility in scheduling. For new project managers learning MS Project, the user scheduling feature may be confusing unless the appropriate amount of training is provided. Demonstrating how to develop a schedule in manual mode and transitioning to auto scheduled tasks increases the learning curve.

Make your own decision

Microsoft provides an entire video tutorial on user controlled scheduling and additional tips and tricks at http://www.microsoft.com/project/en/us/user-controlled-scheduling.aspx. I encourage you to wa tch the demo videos at http://www.microsoft.com/project/en/us/demos.aspx. I will be ensuring the New Tasks Created scheduling option is set to Auto Schedule in MS Project’s Options settings but I’d like to hear your opinion.

Improving Project Status with Visual Reporting

andy@tacticalprojectmanagement.com (Dr. Andrew Makar) — Fri, 18 Mar 2011 18:43:20 GMT

Google has over 13 million pages that describe project status reports. If you read all of them, you’d find a lot of discussions on the purpose of status reporting, key components and numerous templates. I’ll save you the time reading 13 million pages and provide three useful formats to include in your project or program status report deck. The key to these formats is to use visual reports to convey status rather than reading lengthy missive on this week’s project status.

My unscientific observation is people skim rather than read an entire status report or presentation. I’m sure you’ve had the experience where an executive, customer or key stakeholder skims through the first few pages of your meticulously wordsmithed presentation only to stop at the one key slide that holds their interest. The entire purpose of the status report is to inform the project stakeholders of project progress and have a conversation about the scope, resource and timeline concerns. Having a conversation using paragraphs of text is difficult for both the presenter and the audience. Visual formats help make the conversation easier.

I’ve always been a fan of a visual one page status report to convey overall project status. Clark Campbell even wrote two books on using a one-page status report for both information technology and non-IT projects. Be sure to check out The One-Page Project Manager: Communicate and Manage Any Project With a Single Sheet of Paper and The One Page Project Manager for IT Projects. I’d also readily admit a one-page status format may not meet all stakeholder communication needs. To address different communication needs, I’ve used the following one page visual reporting formats to improve the status reporting.

A Status Based Work Breakdown Structure

The figure below depicts all the reports, interfaces, conversion programs, enhancements and forms (or screens) required to be developed in a systems project. Each deliverable in the WBS can be color coded based on progress, issues and risks. The color blue is used to indicate a completed deliverable, yellow indicates an at-risk deliverable, red indicates a late deliverable and green indicates the task is on schedule. A quick glance of the graphical WBS indicates the project’s interfaces and screen development have the greatest number of problems and the conversion branch is also at risk. By adding a visual layer to quickly summarize status, project teams can focus on the issues affecting the impacted work.

Figure 1. Status Based Work Breakdown Structure

The graphical work breakdown strucutre was developed in Mindjet MindManager. Using MindManager, project managers can import MS Project data, assign task start and end dates and display red and yellow indicators based on the current date. I’ve used this visual status reporting format on larger programs and found it helpful in reporting a summarized status of the complex projects within a program.

A Graphical Timeline View

Every project status report needs some type of time-phased Gantt chart to indicate progress against due dates. Prior to MS Project 2010, Gantt chart reporting was difficult to easily depict meaningful tasks in a graphical one-page view. Fortunately, with MS Project 2010, you can create a timeline view and add select tasks rather than adding every task or milestone in the project. The following link contains my tutorial on how to create a timeline view in MS Project 2010.

Figure 2. MS Project 2010 Timeline View

The timeline view is a useful view however, large scale projects and programs often have many workstreams and phases that require an integrated view. MS Project 2010 users can create multiple timeline views and embed them in a single PowerPoint slide or a manual phased-based Gantt chart can be created in Visio, Excel or another graphic program. The challenge with these solutions is they all require tedious graphic manipulation when the project data changes. If you are looking for a configurable, one-page snapshot based on your project schedule, then take a look at Chronicle Graphics OnePager Pro tool.

With OnePager Pro, I can quickly develop a one-page snapshot, report baselines, critical path, % complete and add my own annotations. If the underlying project data changes, I click a button and the graphical data is updated. Try doing that with a complex chart in MS Powerpoint and you’ve just wasted another hour tweaking and shifting data and Gantt bars manually.

Figure 3. Chronicle Graphics OnePager Pro

My One Page Status Report

If I had to include one slide to in a status reporting deck, I would use this format. The format combines text and graphical indicators that include subjective sections and objective metrics like SPI and CPI. By combining the achievements, top issues, risks and schedule, stakeholders receive a comprehensive view of the project all on one status report.

Figure 4. One Page Status Report

I’ve used this format for small projects, large projects with several workstreams and large programs with many sub-projects. By assigning one-page to each workstream in the project, the project manager gets an consolidated view of all the work in the project. As new scope or phases are added, another one-page sheet can be appended to the status reporting deck.

Putting it all together

Once I have the various one-page snapshots assembled, I insert the images into a MS Powerpoint presentation in the following order:

Title Slide with date and presenter
Status Based WBS (Figure 1)
Graphical Timeline View (Figure 2 or 3)
One Page Status Report (Figure 4)
Appendix
1. Detailed Issue, Risk Log
2. Summarize Project Schedule
3. Budget Detail

Additional one page status reports are added for each project in the program. Depending on your need, adjust the slides based on your audience. Thinking visually and communicating in visual formats help comprehension and communication. Pick one of these reporting formats and test it out in your organization.

P.S. If you want a copy of my one page status report template, you can get it with MS Project Tutorial #3 - Project Status Report and Tracking Software.

Mind Mapping Across the Project Lifecycle

andy@tacticalprojectmanagement.com (Dr. Andrew Makar) — Tue, 15 Mar 2011 18:42:18 GMT

On March 15th, I had the opportunity to speak to the Great Lakes PMI Chapter on the topic of applying mind mapping across the project lifecycle. For the past 5 years, I've been working with different mind mapping tools to help improve project delivery using visual thinking. Mind mapping can be easily applied to many processes across the project management lifecycle phases.

During the discussion, I highlighted 3 tools project managers can consider for combining mind mapping and project management

All have free trial versions and have different price points for their professional versions. I recommend you download each of the packages, evaluate them and create your own mind maps to support your project management delivery.

In true mind mapping fashion, I delivered the talk using a mind map instead of PowerPoint. If you'd like to review the presentation, you can download the zip file with the PDF examples below:

Mind Mapping Across the Project Lifecycle

Feel free to recreate the mind maps included in the presentation!

If you want to learn more on how to apply mind mapping to project management using Mindjet Mind Manager, check out my Mind Mapping Project Management eBook and project management templates. The ebook uses Mindjet Mind Manager, however, you can apply any of the aforementioned tools to the concepts.