PM-Foundations – What Does a Project Manager Do?

One of my favorite questions to ask potential project management candidates is, “When you were managing the project what did you actually do throughout the project delivery process?” It is amazing how vague and ambiguous the responses can be.

“I managed the project deliverables.”

“I led the team.”

“I guided the project.”

“I managed customer relationships.”

“I facilitated project planning.” (this one is a little better)

None of these examples very effectively describe what the project manager actually “does” to ensure the project is planned, executed, and closed in a manner that delivers on customer expectations. The other response that I frequently get to this question is a “deep dive” into the content of what was delivered. For some reason candidates think describing what was delivered articulates their contributions to the project outcomes.

The reason I think it is so important for candidates to be able to clearly describe what they do as a project manager is that it helps identify whether or not they consistently do the right things at the right time during the project delivery process. Focusing on the key elements of what a project manager does is also helpful to identify improvement areas and professional development opportunities when coaching and mentoring project managers. Below are 9 of the project management activities that I focus on when working with project managers. I thought about ranking these in order of importance, but honestly I believe these represent the handful of things that are all important for a project manager effectively and efficiently perform to consistently drive positive project outcomes (therefore these are in no particular order).

Top 9 Things a PM Does throughout the Project Life Cycle

1. Create and Manage the Project Schedule – Without a good schedule that directly supports the project objectives (scope, time, and cost), the project manager will struggle to effectively deliver on customer expectations. The project manager has direct responsibility for creating the project schedule, including defining the work breakdown structure (WBS), performing activity definition and sequencing, loading and leveling resources, and performing schedule analysis. During project execution the project manager updates the project schedule in a consistent and timely manner. These updates ensure that the project schedule always provides an accurate picture of work completed, and work remaining to be completed.

2. Create and Manage the Project Budget – The project manager creates the project budget by efficiently leveraging the planning assets created to that point in the process. The project manager performs analysis to develop a project budget that will be understood and approved by the client/stakeholders, and just as importantly can be managed throughout the project life cycle. Creating the project budget includes developing a project staffing plan that details planned resource utilization (in hours), identifying other project costs (e.g., software licenses, infrastructure investments, and travel & expenses), and complying with the organization’s financial processes (e.g., capitalization, investment approval, project budgeting vs. funding). During project execution the project manager updates the project budget with actual hours reported by project resources and other actual costs incurred (e.g., from vendor invoices). The project manager forecasts cost variances based upon costs incurred and estimated cost to complete the project, and identifies / implements corrective actions required to deliver the project within budget.

3. Create the Project Plan – The project management plan represents the key deliverable created during the planning phase of the project that connects the project management activities throughout the project life cycle. The project management plan describes the elements of the baseline project plan (scope, timeline, costs and resources), as well as the approach, processes and tools that will be utilized to manage each component of the project (e.g., cost management, schedule management, change management risk management, roles & responsibilities, project communications). The project manager ensures that a strong project management plan is efficiently created (the project manager generally authors a large portion of the project management plan), and is proactively utilized throughout the project life cycle to successfully deliver on the project objectives.

4. Identify and Manage Risks / Issues – Throughout the project life cycle the project manager facilitated the investigation of project related uncertainties to identify potential risks of things that may occur that would impact the project (scope, cost, or timing). The project manager is responsible for capturing and tracking risks and issues in a manner that minimizes their impact on the project. The project manager ensures that key risks and issues are reviewed on a regular basis, and the appropriate actions are completed to close issues or reduce the impact / probability of risks.

5. Manage Team Meetings – The two most important team meetings that the project manager has responsibility for are the core team and steering committee meetings. Effective planning, facilitation and follow-up for these meeting by the project manager is a key to ensuring that the core team members and project sponsors are well-informed, focused on the right things, and resolving issues in a timely manner. The project manager creates the agenda, organizes information to be presented, facilitates the meeting, communicates meeting outcomes, and initiates / tracks the follow-up actions from the meeting.

6. Manage Change – Change is an inevitable component of managing a project – nothing works out exactly as planned. The project manager manages change by maintaining the appropriate balance between control and discipline to manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. The project manager establishes the change control process for the project, ensures that potential changes are captured and assessed in a timely manner, implements approved changes by making the appropriate adjustments to the baseline plans, and tracks / communicates the impact of change on the project.

7. Measure and Manage Project Performance – The project manager updates progress against plans (budget and schedule), performs analysis required to accurately interpret the key project performance metrics, and recommends / implements corrective actions. This process is performed in a consistent and timely manner to ensure that problems are identified early on, and the appropriate actions are taken to keep the project on-track.

8. Facilitate Stakeholder Communications – The project manager communicates with key stakeholders in a regular and consistent manner, targeting the messages to specific stakeholder groups using the appropriate communications channels / vehicles (e.g., project update meetings, status reporting).

9. Close the Project – Project closure represents an activity that is often minimized or entirely overlooked by the project manager. At the end of a project, many project managers are hurriedly preparing for their next project or client, and miss a prime opportunity to leave a lasting impact on the client organization. Project closure starts with effectively shutting down project activities, validating all product deliverables are complete & key product issues closed, and smoothly transitioning resources to new roles (onto new projects, or within operational functions). The second component of closing the project is gathering customer input about the project, and summarizing the project results in the form of the final project report (also known as the project closeout report). This component of closing the project includes facilitating the lessons learned process to identify improvement opportunities (things done well, or areas for improvement), and to initiate actionable next steps to improve future projects and upgrade the capabilities of the project office.

How do you know if you are doing the right things?

This represents a long list of things to do on a regular basis – how do you make sure you are focused on the right things? Part of the answer to this question depends on where you are in the project life cycle. During the planning phase your focus is on creating the planning deliverables – the schedule, budget, and project management plan. During the execution phase of the project your focus shifts to updating the schedule and budget, tracking risks and issues, managing change, communicating with key stakeholders, and measuring / managing project performance.

The other element of answering this question relates to establishing a personal organization system that the consistently helps you understand and focus on activities that will have the greatest impact on driving positive project outcomes. Neal Whitten, in one of my favorite project management books, “No-Nonsense Advice for Successful Projects”, talks about ensuring that the project manager is managing the top 3 problems. Neal states, “The No. 1 reason projects run into trouble is that the project manager and other project members lose sight of the problems that need the most attention – the top three problems. The top three problems become the top priorities.” I think this concept relates directly to the everyday life of a project manager. What are the top 3 things that need to be performed / resolved to keep the project moving in the right direction? There are many personal organization techniques that you can use as a project manager to ensure you are focused on the right things. I utilize a project planning pad (see below) to record and prioritize my activities at the beginning of the week. This tool personally helps me maintain focus on the “right things” throughout the week, and summarize accomplishments and open issues at the end of the week. The same organization system does not work for everyone, but my personal opinion is that effective project managers consistently utilize personal organization processes / tools of some shape or form.

 

On a Personal Note: I got the idea to write this blog when I was talking to a good friend of mine the other day, Mark Ducharme, about what people do (at work). He said I know that you are a project manager, but I have no idea what that means in terms of what you actually do when you go to work each day. Thanks for asking Mark!

Advertisements

Using MS Project to Set-up your Project for Success

Project managers that are not as familiar with using tools like MS Project to create a project schedule often “dive in head first” creating their project schedule. These project managers open a new file, start furiously loading project tasks, and the project schedule evolves as project planning progresses. After the project schedule baseline is established, and project execution begins, these project managers begin the weekly battle to maintain the project schedule in a manner that keeps it close to reflecting reality. Some of the telltale signs that your schedule is difficult to maintain include:

  • You change the dependency on a task and the dates do not change
  • You extend the duration and the work hours do not change
  • You add a new resource and the dates change unexpectedly
  • Your schedule shows people working on Thanksgiving and Christmas
  • Durations are displayed in hours, and work is displayed in minutes

I was working with a project manager whose schedule had become so difficult to maintain that he declared that his “tool had become compromised”. This created much frustration for the project manager, but the even worse result was that he was not sure that the milestone commitments established in the schedule were correct or achievable (and he did not know how to fix it).

Obviously, how well the WBS is organized has a significant impact on the ability to effectively and efficiently maintain the schedule throughout the project life cycle. In addition, there are several set-up activities within MS Project that allow the project manager to tailor the project schedule to meet their needs. Paying attention to these set-up activities when the project is first created allows you to better understand and control the behaviors within the schedule as you update the project schedule to reflect progress. The set-up tips described below include defining the project start date and project calendar, establishing default schedule options, and entering your project resources.

Defining Project Information

The first MS Project set-up feature I look at is Project Information. This feature establishes the start date for the project. This feature is also utilized to link the default project calendar to the project. If you are using MS Project Server, the project office has most likely established predefined project calendars. When using MS Project 2010, I generally start with the standard project calendar (see below for setting up the project calendar).

Setting up the Project Calendar

One of the most embarrassing things during a schedule review is when someone points out that you have scheduled resources to work on a holiday. That is why it is a best practice to early on tailor the calendar to accurately reflect your project environment. The project calendar is accessed from the function “Change Working Time”. This function provides the ability define non-working days (e.g., holidays). Again, if you are using MS Project Server, the non-working days are likely predefined on the project calendar you selected from the server configuration.

Setting up Schedule Defaults

One of the most important MS Project set-up functions (and also one of the most commonly overlooked) is Project Options. The Project Options lets you tailor many features based upon your personal preference, but the Schedule Options contains settings that will impact the day-to-day behavior within your project schedule. There are two primary components of the Schedule Options:

  • Calendar Options: These setting are used to define the work week (start and end of the week, hours / day, hours / week, and start and end of the work day). The calendar options may also be configured for specific project calendars.
  • Scheduling Default Settings: These options are utilized to define default settings associated with new tasks. I always recommend that durations are set-up as “days”, and work is set-up as “hours”. Unless there are special circumstances associated with your schedule, these are the most logic units of measure for managing the timeline and work effort. If you are creating a resource loaded project schedule, you should set up new tasks as effort driven. The option that seems to be confusing to project managers is the “task type”. The “task type” is utilized to define which task elements are updated when another element is updated (duration, hours, and resource unit allocations). The table below helps illustrate the update behavior associated with the different “task type” options. My personal preference is “fixed duration”. This option allows you to effectively control / manage the timeline (duration) when making updates to the schedule.

Note: Units refers to the % that a resource is allocated to the task. Fixed duration locks in the timeline and recalculates either units or work.

Defining Resources

Before getting too far into creating the schedule, it is important to define your resource pool in an organized manner. The following are the key elements associated with the resource pool:

  • Name – Use the standard naming convention for loading names in the schedule. It is important to be consistent.
  • Initials – Allows you to abbreviate the resource names for viewing in the schedule (takes up less space on specific views)
  • Group – Allows you to group the resources in a logical manner, either by organization or resource grouping. I generally use this field to define the different type of resources assigned to the project (e.g., project manager, business analyst, developer, QA).
  • Std. Rate – Defines the cost / hour for the resource. This is a key element for project budgeting purposes.
  • Max Units – Defines to what level the resource is working on the project. This is a key element used for resource leveling purposes.
  • Base Calendar – Establishes the working calendar that is used for this resource (may have specific resources with different work times).

If you are using MS Project Server to load projects into your project schedule, you select project resources associated with your project from the Global Resource Pool (vs. entering resources to create the project resource pool).

Note: This is a bit of a milestone on my blog – my 50th post. Hope you enjoy the content as much as I do creating it.

PM-Foundations – Creating an Effective Statement of Work (SOW)

Having spent many years on both sides of the table (client and consultant), I have a pretty balanced perspective of what makes partnerships work well. Most importantly I have seen my share of success and challenges as a result of bad client – vendor relationships. These bad relationships are often the source of less optimal project outcomes, or at a minimum the reason the team had to “win ugly”.

I have a firm belief that the quality of the partnership, and the resulting project outcomes, start right up-front when the agreement between the client and vendor is created. The goal of this agreement is to define the products / services the vendor will provide that will satisfy the client’s needs, and how the vendor will be fairly compensated for the products / services delivered. Problems with the agreement can result in a client not getting what they need, or a vendor not getting fairly compensated for what they delivered. Here are a couple scenarios that help illustrate this point:

Scenario 1: The Unhappy Client

The client sends out a Request for Proposal (RFP) to create a new web site. The client has definite ideas in mind in terms of what the new web site needs to look like and do to drive the desired benefits to the organization. The vendor expresses that this project should be pretty straightforward and they provide the lowest time and cost estimates. They are awarded the engagement largely based upon these estimates. As the project progresses, the vendor expresses that there are more requirements / complexities associated with the solution than originally defined in the SOW. Many change orders ensue and the project slips. Finally, the project is completed, but the client had to forgo certain desired features, paid more than planned, and went “live” with the solution much after the original management commitments. This is not a happy client.

Scenario 2: The Damaged Vendor

The vendor provides a proposal to develop a collaboration portal for their client. The client says that they really want to do business with the vendor, but they do not have funding for the amount proposed. The client convinces the vendor that they can “cut some corners” in a couple areas to meet the desired cost of the engagement. As work progresses, client stakeholders keep pushing for doing things “the right way”, and in the spirit of maintaining a positive relationship the vendor performs much of the work originally proposed. The project is delivered successfully, but not without much pain and additional effort on the part of the vendor.

The processes utilized to create and approve the Statement of Work (SOW) can help both parties establish a strong partnership and achieve positive project outcomes. My insights on this topic are not all about introducing overhead and bureaucracy to crank out an “iron clad” contract, but rather how the client and vendor can work collaboratively to create an agreement that sets up both parties for success (the overused term for this is creating “win-win” situation).

6 Tips on Creating an Effective SOW

1. Understanding of the Problem – In my opinion the most important element of creating a strong agreement is ensuring that the problem to be solved is well understood by all parties involved. Adequate effort must be invested in the client describing the problem, the vendor performing discovery to understand the problem and associated requirements, and the vendor describing their approach to solve the problem. Many of my experiences with bad client – vendor relationships can be traced back to when this process was not completed well. I believe that vendors can consistently separate themselves from the competition by taking the extra steps required to understand the client problem, and effectively articulate their proposed approach to solve the problem.

2. Creating an Acceptable Delivery Approach – The processes and tools the vendor will use to deliver the solution must be compatible with client processes and tools (e.g. SDLC, project management tool). In addition, the approach must be one that the vendor is comfortable using to successfully deliver the solution. If there are specific processes or tools that are critical to compliance with client methodologies, they should be understood and specified in the SOW.

3. Establishing Realistic Estimates & Targets – Both parties must be comfortable with the effort and timelines defined in the SOW. Agreeing to estimates or dates that are not reasonable or achievable will lead to problems in the project delivery process. One of my favorite statements is “the work is what it is, and just saying it will be so does not make it so”. If there are specific concerns about the estimates or timelines, it is much easier to discuss and resolve the issues before the work has started, rather than after a significant problem is encountered during the project delivery process.

4. Defining Roles & Responsibilities – Many agreements fall short in the area of defining roles and responsibilities. Vendors do a decent job of describing the resources that they will require to deliver the solution, but they do not spend as much energy on describing client resource requirements. I think it is most effective to describe the client roles and responsibilities in the context of a RACI Chart, and highlight deliverables that the client is responsible for or is making significant contributions to. In addition, it is important to highlight specific resources or skill sets that will be required to complete key deliverables.

5. Minimizing Assumptions – Assumptions are often overused in an agreement to try to protect a party against negative situations. My experience is that these assumptions are forgotten the moment the SOW is signed, and they can become a source of contention during the project delivery process. The classic “CYA” assumption found in many SOWs is “the vendor will have timely access to client resources to define requirements and approve deliverables.” First of all this statement is not actionable, and secondly it is not helpful to successful project delivery. If there are areas of concern, work together to address the issues in an actionable manner either within the definition scope of the engagement or the project delivery approach.

6. Accounting for Progressive Elaboration – Almost all agreements involve “unknowns”. The SOW must accommodate how the unknown will be turned into a known, as well as how project plans will be adjusted throughout the project delivery process. The most common way (but not necessarily the best way) that agreements account for unknowns is through the description of the change order process. A change order process is required when an unknown is not described in the SOW, and requires additional work when it is discovered in the project delivery process. However, many unknowns are associated with clarifications required (vs. change) during the project delivery process and these situations are best accommodated by reflecting iterations in the delivery approach to confirm and adjust plans accordingly.

PM-Foundations – Why Manage a Project?

The other day I was at a client participating in a discussion on strengthening the portfolio management processes, when someone asked the question, “Do we understand what a project is?” This question made me smile. After all of this discussion, we don’t know what a project is, really? From my perspective it is best to keep the definition of a project very straightforward. A project is an effort to achieve a specific goal that has a definitive beginning and end.

 

When you break down this statement, the following are the important elements:

  • Effort – Projects require resources to complete. These resources generally include money and people. Therefore events that “just happen” are not considered projects (many refer to these as Acts of God).
  • Goal – The goal represents the desired outcome that the project is attempting to achieve. The goal is what defines the end of the project.
  • Beginning and End – The most important element of the definition of a project is that it is a temporary endeavor. Projects always have a beginning and an end (even if the end does not represent a successful outcome). The fact that a project is a temporary endeavor is what differentiates it from an operational process. Operational processes are repeated on a day to day basis to perform on-going business functions.

While most people can quickly agree upon the definition of a project, I think the more important question in the context of portfolio management is, “Which efforts should be purposefully and formally managed as projects?” Many project management enthusiasts would respond to this question with a passionate, “Everything, of course!” I would counter that projects can be managed as actions planned and executed within the context of operational processes. For example, I have seen many continuous improvement type initiatives successfully run “in-line” with the completion of operational work. From my perspective, the organization needs to define the efforts that should be separated from operational work, and managed as part of the project portfolio. This approach allows organizations to focus on achieving successful outcomes on the efforts that directly align with business strategies / priorities. Projects that do not fit in the project portfolio are either thrown out, or completed as part of performing normal business operations.

5 Guidelines for When to Manage an Effort as a Project

Below are my top 5 reasons to formalize an effort as a project, and manage it within the project portfolio.

1. Strategic Initiative – If an effort is tied directly to one of the organization’s key strategies or top priorities, it must be formalized as a project. These efforts need the visibility and rigor that a project provides to ensure the organization is demonstrating and communicating progress on its key strategies.

2. Requires Funding – Efforts that require additional funding / resources are difficult to run “under the radar”. The project initiation process facilitates the justification and approval of funds for these efforts. This process ensures that the organization is investing in the “right” initiatives.

3. Involves Opportunity Cost – An initiative may not require incremental funds, but involves a decision to reassign resources from another effort to initiate this effort. There is an opportunity cost related to stopping or slowing the other effort. Again, the project initiation process facilitates making decisions of this nature, and ensures that resources are working on the “right” initiatives.

4. Cross-Functional – Many efforts require facilitation of decisions and coordination of resources across different areas within the organization. Formalizing the effort as a project enables the level of coordination required to ensure its success.

5. Something New – When an effort is introducing something new to the organization (e.g., process, product, or technology) the effort needs a higher level of visibility to ensure the organization is prepared to accept and effectively leverage the new capability. Formalizing the effort as a project provides this increased level of visibility.

When do you need a project manager?

I feel obligated to discuss a related and somewhat controversial question within the project management community. When should a project manager be assigned to manage a project? From my perspective, all projects must have someone who performs the role of the project manager. I do not believe that projects will be consistently successful without someone that is formally responsible and accountable for what is delivered, when, and how much it costs. The question then becomes, when should the project manager assigned be a dedicated and fully qualified project manager, rather than a person that is performing the role as part of another role on the team (e.g., team lead)? Although I am of the belief that projects are generally more successful with a dedicated and fully qualified project manager performing the role, I do think there are projects and situations that can be successful without one. It is important to understand the project and situation when making the determination of who will perform the project manager role on the team. Here are some things to consider when selecting the project manager for your project.

  • Strategic – Is a key priority or strategy of the organization tied to the success of the project? If the answer to this question is “yes”, you should have a “real” project manager assigned to manage the project. It is common sense that a competent project manager will significantly reduce the risk of a challenged or failed project. Why put a key company priority at risk by cutting a corner on the project manager role?
  • Size & Complexity – As the number of deliverables and activities grows on an effort, so does the need for a qualified project manager on the project. The best indicator of complexity is the number and type of dependencies (both internal to the project, as well as dependencies on external activities or projects). An experienced project manager is going to do a much better job managing a large and complex project schedule, than someone who is performing the function as part of another role. In addition, an experienced project manager will more effectively manage the increased level of change that comes with larger and more complex projects.
  • Resources – Is the core team and stakeholder community cross-functional? Diversity on project teams helps drive better project outcomes, but also introduces challenges in terms of leading and controlling the project. An experienced project manager will more effectively establish and manage expectations on the cross functional core team and within the overall stakeholder community.
  • Cost – Is the cost of the project material to the organization (based upon impact on the investment portfolio or operating results)? Effectively managing a project budget is one of the most common areas that trips up an inexperienced project manager. Experienced project managers understand how to prepare a budget, forecast variances, and as required, implement corrective actions.

 

 

 

 

PM-Foundations – What Makes Projects FUN?

If you have read several of my blogs, hopefully you have picked up on the fact that I am sincerely passionate about project delivery. I am always energized and motivated when a project delivers tangible benefits to an organization. I like project work so much that it spills over into my personal life. It is personally satisfying to evaluate the “before” and “after” on a home project – even if it is something as simple as planting a garden, painting a room, or cutting the grass. So what is it about projects that people enjoy? There must be something there, because people actually volunteer and/or seek out opportunities to be assigned to a project team.

The intent of this post is to prompt some thoughts on the positive aspects of project work, and what you as the project manager can do to enhance team members’ experiences on a project.

What is fun about projects?

These are several of the aspects of project work that is inherently fun and rewarding for project team members.

  • Sense of accomplishment – There is a definite sense of accomplishment when a deliverable is completed, a milestone is achieved, or project is closed. When a project is closed you can observe benefits realized by the organization as a result of the team’s efforts. When a milestone is achieved you move on to a new phase in the project. In contrast, when you complete operational work, there is another “stack” of the same type of work right behind it, with no apparent end in sight.
  • Something Different – Projects provide opportunities for team members to be exposed to new technologies, business processes, and problems to solve. Exposure to new areas represents huge opportunities for team members to learn and develop both personally and professionally. For those of us that thrive on continuous learning, there is nothing better than being assigned to a new client or project.
  • Involves People – Small projects can be delivered by an individual, but the vast majority of projects involve a team of people assigned to accomplish a common goal. The people assigned to the project bring with them a diverse range of talents, experiences and perspectives/ideas. It is this diversity that ensures that the team’s unified efforts are much greater than the sum of its individual contributions. Assembling a diverse group of people as a new project team can be challenging (forming and storming) but it is ultimately very rewarding as the team starts to work well together (norming and performing). I personally find the broad spectrum of people I meet and work with during projects to be the most amazing element of being a project leader.
  • Recognition – All projects have a certain amount of visibility in the organization, otherwise the resources would not be assigned to it. With visibility comes recognition and potentially rewards when milestones are achieved and projects are successfully completed. Visibility can also result in negative consequences when projects are challenged or fail. Based upon my experiences there is far more upside potential associated with positive project outcomes, than risk of negative consequences associated with challenges or failures.
  • Projects End – By definition projects have a beginning and end. Admittedly, some projects are not as enjoyable as others, but at some point they all will come to an end (some more naturally than others). With the knowledge that the project will end, even the worst of projects can have their moments.

6 Ways Project Managers Can Make Projects More Fun

As a project manager, there are a number of things that you can do to establish a positive project environment – one that team members actually enjoy being a part of. These 6 tips are a combination of applying effective leadership skills, and implementing practical techniques to enhance the project environment. My experience has led me to the conclusion that in most cases creating a positive project environment translates into building a more productive and effective project team.

1. Focus on Teamwork – I spend a lot of time making sure the project team understands they are a team working towards a common objective, and not a bunch of individuals assigned to a project. Establishing a group that works as a team starts with making sure the team understands what we are trying to accomplish, and what success looks like. It also includes ensuring that everyone has internalized what their role is on the team, and how their role connects with the success of the overall project. There are things you can do to make sure the group feels like a team. Schedule regular team interactions (team meetings), provide meaningful project updates, and promote collaboration / interaction. Unless this group has worked together before, it takes some real work and focus on your part to make the group feel and interact like a team. Do not be discourage or give up as the team traverses through the forming and storming phases of creating a team. Your leadership can make a significant difference in terms of how the team works together.

2. Be Enthusiastic – Assuming you are like me, and really enjoy project work, make sure the team knows it. You need to consistently model the attitude and enthusiasm you want the team to feel throughout the project. If the project manager does not believe the team can be successful, who does? It is amazing how quickly the team will get discouraged when you display negative vibes about the project either verbally or non-verbally. The easiest way for me to model a positive and enthusiastic attitude during team interactions is to make sure I really do feel that way. When faced with difficult tasks or people, I remind myself what I enjoy about the challenge the project is providing, the team I am working with, and the opportunity to learn something new. This is a critical tip – do not ignore it.

3. Track & Communicate Priorities – This one sounds pretty straightforward, but it is amazing how quickly team members can get “lost in the weeds” or “in a funk” without timely and relevant information about the project. Team members must understand the team’s top priorities, and how these priorities tie to their individual work assignments. Priorities include upcoming milestones, task assignments, action items from team meetings, as well as high impact issues and risks. I try to keep this information simple and easy to consume / internalize – What did we accomplish last week? Where should we focus next week? What roadblocks need to be removed?

4. “Stretch” the Talent – As the team is forming, it is important to get to know the individual team members. Not only do you need to understand their strengths and weaknesses, but also what are the things that motivate and energize them. If you have insights into team member’s professional development path, you can help align work with the areas where they have talents, are excited about, and/or desire to learn. Aligning work and responsibilities in a manner that gives people a chance to “step up” on the team goes on a long ways towards building a highly motivated team that delivers positive results. The opportunities on the team can be both in the form of specific work assignments, as well as roles (e.g., facilitation of team meetings, coordination of team events).

5. Purposeful Recognition – It is extremely important to recognize people’s contributions on the team. There are two categories of contributions that I recognize on the team – (1) efforts that help the team achieve its goals, and (2) efforts that demonstrate or promote teamwork. As the project manager, you are recognizing contributions that helped drive positive project outcomes based upon either the work that was performed, or the way in which it was performed. A significant amount of positive energy can be created on the team by recognizing the right efforts at the right time. The recognition does not need to be elaborate, but it must be sincere, and a bit of creativity helps generate a fun atmosphere on the team. When given the choice of recognizing an individual or a group effort, I generally opt for recognition of the group (sends the right message as a team, and ensures you do not unintentionally leave someone “off the list”).

6. Close the Project – When you have come this far with the team, do not forget to bring appropriate closure to the effort. Effectively facilitating the lessons learned process helps the team reflect on what was accomplished, how it was accomplished, and what would the team do differently on the next project. This is the opportunity for the team to have a real impact on how projects are completed within your organization in the form of implementing continuous improvement actions. The other important element of project closure is celebrating success. Facilitate a project celebration that helps team members feel good about was accomplished before they rush off to their next assignment.

PM-Foundations – Managing Your Project Issues

To me the most annoying, and sometimes the most disruptive type of project churn is issue related churn. Open issues distract team members from the work at hand, and often slow progress to achieve project milestones. At its worse, more time can be spent talking about issues than project work. If the rate of identifying issues outpaces closing them, the project can be overwhelmed with issues. Projects are paralyzed by project issues when team members cannot complete tasks/deliverables because they are awaiting resolution of project issues.

Significant issue related churn is generally due to the project team not having the appropriate focus or urgency required to close issues. In some situations the team is not empowered to take actions or make decisions required to close issues. In either case, issues that do not close create “baggage” for the team, and eventually create roadblocks or challenges for the project.

Hopefully this blog gets you thinking about how to identify when issues are negatively impacting your project, and what you can do to get them under control. Issues are not a bad thing, as long as you are able to manage them, and not vice versa.

How Do Issues Overwhelm Projects?

Here are some of the common indications that issues may be overwhelming your project, or at minimum impeding progress.

  • Too many – The obvious indication of issue related churn is the number of open issues — especially if there are a significant number marked “high” priority. When there are so many issues that you do not know where to start to get them under control, you probably have too many. When the number of issues becomes significant, you start to see processes like “triage” introduced to identify the ones that “really matter”.
  • They bounce around – Some project teams do not seem to close issues, they just reassign them to someone who needs to have another meeting to discuss the issue. A good way to identify the inability to effectively close issues is to look at the history associated with the issues. When issues are owned by multiple people, and the source of multiple meetings, the team is probably not focusing on the right actions required to close the issue.
  • They keep coming back – One of the most annoying aspects of issue related churn is when closed issues are reopened. This occurs if the either the right people were not involved, or the correct actions were not taken to close the original issue. When this happens multiple times on a project I am not sure if I am more upset with the person that reopens the issues, or the person that did not close it properly in the first place.
  • They appear out of nowhere – Often times an issues is raised that makes you wonder, “I wonder why that was not raised before now?” The earlier a potential problem is identified in the project life cycle, the easier and less costly it is to resolve. Therefore, as issues are identified late in the project, the more disruptive issue resolution becomes. As the project manager, you need to strike a good balance between aggressively managing issue resolution and encouraging team members to identify them. The last thing you want is to have team members keep issues to themselves because they think it will be viewed as a “bad thing” to raise a new issue.

6 Tips to Managing Your Project Issues

  1. Capture – My first tip is pretty obvious. Make sure that as issues are identified they are captured. This means that processes and tools must be established early on in the project to enable identification and tracking of issues. In addition, it is important as the project manager to create an environment where people feel “safe” to raise an issue. Having said that, I do encourage the team to be thinking about ways to address the issue at the time they raise it. The old adage “if you are not part of the solution, you are part of the problem” definitely describes some team members.
  2. Accountability – In my opinion the most important element of effectively managing issues is establishing a single person that truly feels accountable for resolving the issue. Issues are best assigned to people that have something “at stake” in the outcome of resolving the issue. The issues should either have an impact on the component of the project they are responsible for, or have an impact on the component of the product they are responsible for.
  3. Action – When team members are providing updates on issues, the focus should be on what actions have been identified to close the issue. I do not necessarily consider “we have a meeting set up to discuss this issue” to be a very effective next step. The more appropriate action items are focused on what decisions need to be made, analysis performed, or requirements defined to determine how to move forward and resolve the issue.
  4. Measure – As is the case in most project management processes, it is important to have the appropriate metrics in place to manage issues. To establish a high degree of focus and sense of urgency, I prefer to measure and communicate high priority issues in the form of absolute numbers. Metrics like net change and average age are best managed through trend analysis. In addition, it is important to keep track of the overall impact of issues on the project. This metric can be tracked within the change control process.
  5. Close – Ensure that the issue management process includes a step to validate that the issue is actually closed. This step can be as simple as a quick review of the recently closed issues in your core team meetings. It is important that team members agree that the appropriate actions have been taken to permanently solve the problem.
  6. Timeout – If an issue, a group of issues, or the issues in aggregate are truly overwhelming your project it is sometimes appropriate to bite the bullet and call a timeout. This happens when issues are causing the project to miss significant milestones, and corrective actions are not in place to formalize the impact and get the project “back on track”. During the timeout, focused effort should be placed on resolving the high impact issues, reducing the overall number of issues, formalizing the impact of the issues, and rebaselining the plan. I also recommend a quick lessons learned process to identify the source of the problems, and adjustments required to prevent the project team returning to the same place during a future phase of the project.

PM-Foundations – Sizing Your Project Management Processes

On more than one occasion I have mentioned that project management processes should be sized appropriately for your project. I truly believe that “one size fits all” is not an effective approach to implementing project management processes. It is important to strike the right balance between establishing “heavy” processes that constraint progress, and running your project with little or no focus on how the work will be managed. As I recently discussed in my post on project churn, process churn is a perfect example of “one step forward, and two steps back” – either it is way harder to get things done than it needs to be (too heavy), or there are wildly different outcomes depending on the person performing the process (too light). With the right balance, project management processes enable project work to be completed in a repeatable and efficient manner.

I am not a fan of having two sets of process – one for big projects, and one for small projects. The preferred approach is for the project office to establish project management processes that are appropriate for the organization and the project environment. As a project is launched, these processes are tailored to meet the needs of the specific project scope and complexity. In this blog I discuss the key characteristics of project management processes (what makes them too “heavy” or too “light”), the “critical” few processes to focus on, and how to adapt these processes to the specific needs of your project.

Key Characteristics of Project Management Processes

The characteristics associated with the project management processes really define how appropriately they are sized to deliver your project in an effective and efficient manner. Below are the characteristics that I generally focus on when tailoring the project management process during the launch of a new project.

  • Time – This one is kind of obvious. How long does it take to complete the process (in terms of both duration and effort)? Is the time invested in the process appropriate based upon size of the project and the potential impact of the process on the project? Many teams inadvertently build time into the process. Examples of time built into the process include forms that take hours to complete, or approvals that only happen once a week.
  • People –Who is responsible for initiating the process? How many times does the process move from one person to another? How many people are involved in the review and approval process? Involving more people in a process mitigates the risk associated with errors or bad decisions, but also adds time and overhead to the process.
  • Documentation – Is the process documented? Is process documentation leveraged to perform the process in a repeatable and efficient manner? Process documentation maintained by the project office is helpful as a starting point, and adjustments to size the process for your project (tailoring) should be the focus in the project management plan.
  • Artifacts – What artifacts are created through execution of the project management process (e.g., spreadsheets/lists, forms)? Are the artifacts a by-product of executing the process, or do they represent additional steps/work? Artifacts are not free, therefore it is important to assess whether or not they add value to your process.
  • Tools / automation – When you talk about tools and automation, by default you think “faster” and “less effort”. In reality, introduction of tools and automation is where project teams have a tendency to add the most overhead to their processes. I have seen many examples of tools that are “over-engineered” for the problem they are trying to solve, and add overhead to the process (vs. streamline it).

The “Critical Few” Project Management Processes

Establishing, implementing, and re-enforcing best practices around the “critical few” project management competency areas will represent the difference between a successful and challenged project. The “critical few” competency areas is also where you should focus to appropriately size your project management processes.

  • Change management – How are change requests initiated? Who assesses the impact of the changes? Who reviews and approves the changes? How are changes implemented? How is project change measured and reported?
  • Issue & Risk Management – How is project risk assessed at the beginning of the project? How are risks updated throughout the project? How are issues identified and tracked? Who is accountable for mitigating risks and closing issues? How often are risks and issues reviewed as a team? How are issues and risks measured and reported?
  • Schedule Management – How and when is the schedule regularly updated to reflect progress? How is the progress communicated to the team? How are corrective actions identified and communicated?
  • Cost Management – How are actual costs captured? How are project purchases initiated? Who approves project purchases and payments? How are budget variances and corrective actions identified?
  • Project Communications – What is the format and content of project status reports? What is the process for preparing, reviewing and distributing project status reports? Is relevant project information available to stakeholders? How does the project team interact on a regular basis? Does the team have regular team meetings? How is the project sponsor updated throughout the project life cycle?

The table below provides some indications that project management process may be “too heavy” or “too light” for each of the “critical few” competency areas.

Process Area

Too Heavy

Too Light

Change Management

  • The change request takes a significant effort to complete due to all of the information required
  • A lot of people are involved in the assessment and approval of the change request
  • Changes get lost in the approval workflow
  • It seems like it takes forever to implement change, even when everyone thinks it is the right thing to do
  • Change is not documented or communicated
  • The impact of change is not assessed before it is approved or implemented
  • The actual impact of change is not measured or managed

Issue & Risk Management

  • It takes significant effort to document an issues due to all of the information required
  • Issues and risks are reviewed more frequently than the pace of actions to mitigate or close issues and risks
  • The number of issues and risks tracked is overwhelming to the project team
  • Issues get lost in the resolution workflow
  • Risks are not assessed at the beginning of the project, or routinely reviewed throughout project execution
  • There is no clear accountability established to manage an issue or risk
  • Risks and issues are not documented or updated in a central repository accessible to the team

Schedule Management

  • It takes significant effort to complete project progress updates because it tracked in so much detail
  • There are multiple layers of management involved in capturing progress
  • By the time the schedule is fully updated, it is time to start the next reporting cycle
  • So many reports are produced that it is difficult to understand what to focus on to understand where the project is at
  • The project schedule is not updated after project planning is completed
  • Schedule slippage is identified and reported after the fact (or not at all)
  • The team is not tracking or managing to key project milestones

Cost Management

  • Financial tracking and reporting tools are cumbersome and time consuming
  • Creating purchase orders and statements of work frequently delay project work
  • Multiple layers of management are required to approve invoices for work that has been acknowledged as delivered by the project team
  • Actual effort is not captured
  • Vendor invoices are approved and paid without confirmation that the required work was performed
  • Vendor invoices are approved and paid outside the scope of the project management processes
  • Variances are discovered after the cost has been incurred
  • There is no accountability for actual effort or cost compared to the amount budgeted

Project Communications

  • The project status report is more than 2 pages
  • Multiple project status reports are prepared (for different stakeholder groups)
  • Team meetings consume more than 10% of the time spent on a project
  • Team meetings are redundant in nature (same topics discussed with multiple audiences)
  • Stakeholders are not sure how to obtain the latest project status
  • The core team does not regularly communicate as a group
  • The project sponsors are not provided project updates on a routine basis

 

How to strike the right balance

Striking the right balance to implement effective and efficient processes for your project involves a combination of leveraging the process assets of the project office, and tailoring the processes to meet the specific needs of the project. The specific needs of the project area determined based upon the size (people, costs, duration) and complexity (internal and external dependencies) of the project. The investment in each of the process areas should be appropriate based upon the potential impact on the project. Does the process add value to the project execution, or add unnecessary overhead?

Striking the right balance from project to project becomes more effective within the project organization when critical processes are documented in a usable and accessible format, and consistently leveraged by project managers to create the “right” processes for each project. The tailoring of project management processes represents a key component of the practical application of best practices for successful project delivery. The more ingrained these best practices are in the project management culture, the lower the dependency on the talents and heroic efforts of individual project managers.

Using MS Project to Manage Project Milestones

 

 

The PMBOK® describes a milestone as a significant point or event during a project. Project milestones are also referred to as a Phase Gate, Stage Gate, Check Point, or Decision Point. In other words a milestone represents a significant point in time when a predefined segment of work has been completed, or the when a specific event has occurred.

 

Some examples of common project milestones include:

Recognizing Work Completed:

  • Project Baseline Complete
  • Technical Design Complete
  • Code Complete
  • System Testing Complete
  • Iteration 0 Complete
  • Sprint 1 Complete

Recognizing Events Occurred:

  • Business Case Approved
  • Software Solution Selected
  • Proof of Concept Approved
  • Software Installed
  • User Acceptance Test Approved
  • “Go Live”
  • Project Closed

A milestone may be mandatory, acknowledging compliance with external regulations or the organization’s SDLC, or optional in nature, recognizing completion of specific project work or events. In either case, managing milestones enables effectively measuring and communicating project performance throughout the project cycle — rather than waiting until the end of the project “hoping” the project is successfully delivered. I have been in more than one project briefing where a project stakeholder stated, “Shouldn’t we have known about this problem earlier in the project.” In every one of these situations, if milestones were established and managed properly, the problem would have been identified, and corrective actions implemented much earlier in the project life cycle. MS Project provides several features that enable establishing, and managing project milestones. I describe several of these features below in my 5 tips to manage project milestones.

5 Tips to Manage Project Milestones

1. Highlight key “junctures” in the project – During the process of creating the baseline project plan, milestones should be purposefully identified and inserted into the schedule. These milestones highlight compliance with SDLC requirements (e.g., stage gate approvals), completion of specific work or events (e.g., requirements complete), or connections of project work to external dependencies (e.g., approval of project deliverables by a government agency). These are all planned points in time during the project that you will measure planned vs. actual progress (time, effort, cost, and scope). For this reason you want to make sure that milestones are “sprinkled” throughout the project life cycle — milestones should be inserted every 10-20% of the overall project duration. Within MS Project a milestone is established by inserting a task with 0 days in duration (depicted with a u on the Gantt chart). I also find it helpful to highlight the project milestone with a different color text (see sample MS Project schedule below). In addition, MS Project provides filters and views that effectively communicate the project milestones.


2. Understand dependencies – Connecting predecessors to project milestones defines the work or events that must be completed to “declare victory” for that point in time during the project. In other words, dependencies are utilized to define what “done looks like” for each project milestone. In addition, dependencies attached to the milestone establish triggers for work to be initiated upon completion of the milestone (in the form of successors). Effectively planning the milestone successors helps ensure a smooth transition between phases / stages of the project. The picture below depicts using the MS Project’s Predecessor – Successor view to establish and review the dependencies tied to the project milestone.

3. Progress measured based upon milestones – Special attention is paid to project performance as it relates to project milestones. Finish variances tied to the project milestone are utilized to identify how completion of the milestone is tracking (vs. baseline plans). As variances are identified, dependent tasks / deliverables are reviewed to identify the source of the schedule related problems, and identify / implement the appropriate corrective actions. This represents an effective and efficient approach to quickly review and communicate project performance. Below is an example of tracking schedule performance associated with project milestones.


4. Change assessed based upon impact on milestones – The schedule impact associated with a project change must be assessed based upon impact on the project milestones, as well as the end of the project. Managing impacts at the project milestone level ensures that all stakeholder commitments are understood before implementing change requests (e.g., external project dependencies, scheduled events). Simulating the implementation of the project change within the project schedule provides in a very tangible manner the impact of the project change on the project milestone (see sample below).


5. Celebrating Success & Capturing Lessons Learned – It represents a best practice to celebrate success and capture lessons learned at project milestones. Milestone based celebrations energizes teams to take on the next phase of the project. As I mentioned in my blog on Project Celebrations, the celebrations should “sized” appropriately based upon the event or work completed. Capturing lessons learned at the end of a project milestone provides a couple valuable benefits:

  • It is most effective to capture lessons learned while they are “fresh” in the minds of the project team.
  • Capturing lessons learned at project milestones provides the ability to implement actions that will improve the team’s project delivery capabilities in future project phases. This approach is actively practiced in Agile projects, in the form of retrospectives performed at the end of each sprint.

Using SharePoint to Communicate Milestone Progress

While MS Project provides strong capabilities to identify and track project milestones, the project site on SharePoint can be leveraged to communicate the current status of project milestones. I utilize a custom list to create the Milestone Tracking list in SharePoint. Many stakeholders do not have access to MS Project, and the milestone list represents an easy to access and understand vehicle to consume milestone performance related information. In addition, this list can be easily incorporated into the on-demand project status report available on SharePoint.

Avoiding 7 Pitfalls – Using SharePoint to Improve Project Delivery

SharePoint 2010 is an enabling tool utilized to dramatically change the project environment. Creating a more productive project environment helps you launch the continuous improvement phase of your Project Management “Best Practices” program from a more efficient and effective starting point. Key elements of a more productive project environment include:

Collaboration – Enhancing your project environment to create more effective interaction between team members.

  • Providing a single source for the truth
  • Upgrading version control for key project artifacts
  • Establishing closed loop communications

Streamlining Processes – Utilizing a tool to establish or enhance project management related processes.

  • Establish structure via lists and libraries
  • Use workflow and alerts to reduce cycle time associated with reviews/approvals

Measuring Performance – Capturing the data required to measure project performance, and make the appropriate “course corrections”.

  • Measurements are a by-product of the project work performed
  • SharePoint provides a platform to communicate “real-time” project performance metrics

I have worked with a number of clients that have seen some incremental improvements in their project environment using SharePoint, but they have not realized tangible improvements in their project delivery outcomes. I will generally find common themes / problems in situations where SharePoint has not enabled more consistent and effective application of project management of best practices, and improved project results. These are all pitfalls that can be avoided with a well planned and executed SharePoint implementation to upgrade your project environment.

7 Pitfalls to Avoid

1. Do Not Move Beyond Document Management – Most teams start with using SharePoint to store project artifacts. In most cases this represents a technology related improvement (from share drives to SharePoint), but the tangible benefit of this function is limited to making it easier to find documents with a better search engine. I encourage teams to launch the new project sites with more than document libraries right out of the “starting gate”. Making the leap to using SharePoint as more than a document repository after the initial launch of the new project site always seems to require more focus and effort to achieve successful adoption of the new processes.

2. What Best Practices? – Many teams launch the new project site, and then start to think about what they could use it for. It is best to identify the core project processes and best practices that you want to improve through the implementation of SharePoint in your project office before the launch of the new project site. Project management best practices that are prime candidates to be incorporated in your SharePoint implementation include:

  • Organizing Project Deliverables
  • Managing Risks & Issues
  • Change Management
  • Managing Project Milestones
  • Project Status Reporting
  • Team Roles & Responsibilities
  • Project Meetings
  • Project Metrics

3. Teams Building “Their Own” – Trust me on this one, you do not want teams starting from a blank project site, and creating their own project management “best practices” on the fly. It pays huge dividends to take the time up-front to create a “template” for the project site. This template is used to create each new project site. The template ensures that the teams have a common “starting point” for implementing project related process. The project template also ensures that project metrics and reports are created in a consistent manner, and enables more effective “roll-up” of information to the project portfolio level. The following are examples of what should be included in the definition of the project site template:

  • Definition of metadata (e.g., definition of project status – Red, Yellow, Green)
  • Site permissions, using predefined project roles/groups
  • Libraries for project deliverables, organized in a consistent manner
  • Lists for managing key project information (roles & responsibilities, risks & issues, change requests)
  • Predefined workflows for specific processes that involve reviews / approvals (e.g., change control)
  • Views for communicating information to stakeholders in a consistent manner

4. Integration Gaps – Working at clients that do not have SharePoint fully integrated in with their overall infrastructure makes you understand the impact integration can have on your SharePoint implementation. For example, when clients do not have “single sign-on”, your team quickly gets annoyed with logging onto SharePoint each time they access the project team site. Pretty soon you find they access the site less frequently, and do not view it as a core element of completing project work. Another example of integration of SharePoint within your overall infrastructure is email. When your infrastructure does not include Outlook 2010, the project team cannot take advantage of the integration to fully automate workflows (e.g., approval of project changes) or manage team meetings (e.g., meeting workspaces).

5. Collaboration is Not a “Team” Thing – If the project team sees the value in the collaboration tools and processes, they will take ownership for updating and maintaining the project site. The value of collaboration is significantly diminished if the project manager is the only person providing updates to the project site.
The collaboration tool must represent the single source for current project information. As the project manager, you need to make sure team members use the tool in this manner (e.g., discourage people from maintaining work in progress offline on their own laptop).

6. Over Engineering the Project Sites – Many clients have a tendency to over engineer the project sites. Over engineering presents itself as elaborate structures for document libraries, capturing too much information to perform processes, or creating complex workflows for reviews and approvals. Ultimately adding all of these “bells and whistles” makes it harder for project teams to understand and utilize the site, and usually does not do anything in terms of driving better project results. The project sites should be set-up in a manner that requires very limited training to on-board new team members. In addition, avoid creating document libraries with many levels of folders – use metadata to organize the documents.

7. Projects End, Make Sure Your Artifacts Do Not – With a little luck, your projects have a beginning and an end. Decisions need to be made at the end of the project in terms of what happens to the project site. The information captured on the project site throughout the project life cycle represents intellectual property that can be leveraged to improve future project delivery efforts. Organizations that do not purposefully store and utilize project archives generally make minimal progress in the area of continuous improvement.

A Proven SharePoint Implementation Approach for your Project Office

The standard approach related to implementing a collaboration platform to upgrade your project environment includes the following:

  • Identify (or confirm) the “critical few” best practices that should be emphasized and integrated into the collaboration platform.
  • Establish some standards / guidelines that would be used by each of the teams (and a place where these standards are accessible). Some examples include:

    When to create project site

    What are the standard elements of the project site

    What meta-data is important for standard reporting or site organization

    Create templates for key lists and libraries (risks/issues, change requests, status reports document libraries)

  • Depending on the experience of your project team, you may need to provide training for the team on SharePoint. At a minimum you need to get your up to speed on the specifics associated with the implementation of SharePoint within your project environment.
  • Get started. Don’t wait until everything is perfect before you launch your new project environment. You will never get complete consensus on the standards/guidelines, and there is an opportunity cost associated with delaying the launch of your new project environment.
  • Establish processes to identify and capture best practices in the context of your new project environment. As these ideas are incorporated into the standard best practices they will be reflected as tangible continuous improvements.

 

 

 

PM-Foundations – Using Progressive Elaboration

Have you ever been assigned a project that seems to be “stuck” in the starting gate? There are stakeholders that support of the project, but there are too many unknowns, and not enough funding, to get the project launched properly. Here are some of the usual characteristics of this scenario:

Benefits: The benefits have not been fully developed. Benefits have been identified at a high level, but measurable benefit targets have not been established, or committed to. Stakeholders feel that quantifying the benefits will be dependent on making significant product and project related decisions (requirements, solutions, costs, time to market).

Requirements: Requirements are at too high a level to be able to define the work to be completed. Resolving open requirements related decisions, and adding specificity to the requirements will have significant implications on timelines, work effort, and cost estimates. Stakeholders also feel that requirements will be influenced by the capabilities and costs associated with potential solutions.

Solutions: There are several options available to solve the business problem. The different options have a wide range of costs, capabilities, and effort/time to implement. Decisions cannot be made on the final solution until due diligence on the solutions options is completed, and the requirements are more fully defined.

Funding: Project sponsors feel that the project has strong management support, but funding cannot be obtained until the business case is developed. The management team feels that without the business case they will be signing a “blank check” with no commitment on the project ROI. For the business case to be finalized the team needs to understand more about the benefits, requirements, and solution options.

In this scenario you often feel that you are caught in a “chicken and egg” type situation – which comes first the benefits, requirements, solutions, or funding. The obvious answer is you need to go through the planning process to make relevant product and project related decisions, and establish the baseline plan. However, given this scenario there are still several challenges with getting the planning process launched:

  • Based upon the significance of the unknowns at the starting point of the project, there are a wide range of outcomes from the planning process – benefits, requirements, solutions, costs, and time to market.
  • Due to the size or complexity of the business problem, the planning process represents a significant effort.
  • Funds or resources are not approved to complete the planning effort.

What should you do? This situation represents a great opportunity to apply progressive elaboration techniques (also known as, rolling wave planning). The PMBOK® describes rolling wave planning as a progressive approach to detailing the project management plan, where planning and supporting processes are completed in an iterative and on-going manner. This means that you plan to define and refine the project management plan beyond the initial planning process – completing project work to turn an unknown into a known, and updating the plans accordingly. Below I discuss several tips to using progressive elaboration to effectively launch & plan your project, and manage stakeholder expectations.

An aside on the analogy of “peeling the onion” to describe progressive elaboration: Completion of the project planning process is utilized to remove the surface layers of the onion. In many projects you are able to quickly cut through a cross-section of the onion and get a clear picture of the onion layers (future project work). In other cases, due to the complexity / size of the business problem, you need to “peel back” many layers of the onion before you are in a position to cut through a cross-section of the onion to understand the full scope of the product and/or project. This is the situation where progressive elaboration represents an effective project delivery technique. There are things you can do as a project manager to effectively manage stakeholder expectations during the process of “peeling the onion” using progressive elaboration techniques to establish an effective project delivery approach – no need for tears during this process.

6 Tips on Using Progressive Elaboration

1. Plan what you know – The place to start is to develop detailed plans (scope, schedule & cost) for the work that is required to better define the product and project. Many people would refer to this activity as the “plan for the plan”. This initial planning effort may require a single iteration or several iterations to complete, depending on the size and complexity of the business problem to be solved. Developing this portion of the plan allows you to talk to project sponsors about what it will take to make key product and project decisions, and develop a baseline plan. This plan will include many of the following key deliverables:

  • Business requirements
  • Solutions Analysis
  • Solution Selection
  • Project Management Plan (project schedule, project budget, project scope)
  • Business Case (project ROI)

2. Use Planning Components – Decomposition of the plan will not be possible for all deliverables or components of the project (sub-projects) for future phases. Planning components are inserted into the WBS to depict deliverables or sub-projects that cannot be decomposed to the work package level. The planning components represent “placeholders” for the project areas with significant unknowns. Without planning components it is not clear to stakeholders the areas where additional work will be added to the plan upon completion of the initial phases of the project. It is difficult for stakeholders to visualize deliverables and sub-projects that are “missing” from the initial plan.

3. Establish a timeline & a rough order of magnitude – One of the problems that stakeholders have with progressive elaboration is that they are uncomfortable investing in “up-front” work without having any visibility of what the “end game” looks like. Inserting planning components to depict future phases, and assigning rough order of magnitude type estimates (-10% / + 50%) helps establish an early perspective of the overall project plan (timeline and cost). This approach creates angst for many project managers because they believe that once an estimate is presented (no matter how preliminary it is), it is the date or cost that stakeholders will remember. My response to this concern is that there will be many situations where the stakeholders will not give you a choice but to present the “entire” picture. When I put together a plan in this scenario, I clearly depict the timeline and budget in two buckets: 1) what is known vs. 2) what is unknown. I will also clearly articulate the difference in level of precision associated with the two buckets.

4. Insert meaningful milestones – Milestones always represent a key component of a good plan because they highlight key events or achievements within the plan (e.g., approval of key deliverables, completion of project phases). With the use of progressive elaboration, milestones take on new meaning and importance. They represent points in time when the project team will have more information, and plan to make adjustments to the project plans. In most cases, there will be a milestone that establishes when the project baseline for the entire project will be completed and approved.

5. Get funding for the first “wave” – The key to the initial planning effort is to clearly articulate the scope, timing and cost associated with establishing the plan for the entire project. Your goal as the project manager is to obtain the funding for the “up-front” effort, and approval to launch the project. Before the project will be funded and launched you must convince key stakeholders of two things:

  • Based upon what we know today, this project has enough merit to invest in an “up-front” planning effort.
  • The “up-front” effort will be successful based upon the information detailed in the project management plan (scope, schedule, cost, and project management approach).

6. Progressive elaboration in an Agile delivery model – By definition, rolling wave planning represents an iterative approach. Therefore, this approach can be adapted well to an agile delivery model. Many agile teams refer to the “up-front” effort as “Iteration 0”. During “Iteration 0”, the team defines, priorities & estimates the product backlog, creates the initial product roadmap (articulating the initial content of each sprint), and plans the first sprint in detail. At the end of each sprint, the agile team will continue to use progressive elaboration techniques to re-prioritize the product backlog and adjust the product roadmap.