Voices on Project Management

> Back to Voices Home

More posts in Project Planning

6 Obvious Budget Overruns to Avoid

| | Comments (0)
Voices_Marian_Cost Overruns_v2.png

Nowadays, we rarely hear about projects that finish below a given budget. On the contrary, we hear about projects that need more people, more material resources and more time, which ultimately translates into additional costs that strain the project budget.

Although it is clear that project costs can be influenced by external factors beyond the project manager's control, there are at least as many factors that can be controlled from within the project, through appropriate project cost planning.

Here are six simple reasons that projects incur cost overruns -- and how to prevent them:

1. Underfinancing. You've probably heard about projects that start with an undersized budget ("We could only allocate that much for this project..."). Such projects will have a high risk of overrunning the initial budget, as well as a high risk of failure. 

Mitigation: Clarify with the project sponsor from the very beginning how cost overruns, which are very likely to occur, will be handled -- for example, through scope reduction or additional funding.

2. Unrealistic costs estimates. Projects that have costs estimated based on gut feelings or inexperienced personnel are poised to face budget overruns. Biased and inaccurate cost estimates are likely to look unrealistic at a later stage in the project.

Mitigation: Break down the work into smaller and more assessable packages. Get help from subject matter experts and experienced personnel when estimating costs. Make the cost estimations comprehensible, by applying different estimation techniques (e.g., three-point estimates, parametric estimating or bottom-up). 

3. Underestimated complexity. Many projects nowadays, especially larger ones, have constantly growing complexity. The Berlin Brandenburg Airport and Terminal 1 of Munich Airport, for example, were quite similar in scope, but conducted at different times (25 years apart). Yet Berlin Airport, the more recent project, continues to have considerable budget overruns and delays. One of the reasons: the underestimated complexity concerning the financing of the project, the construction of futuristically designed facilities and newer regulations.

Mitigation: Split the project in smaller work packages or phases. Avoid planning everything extensively from the very beginning (the planning alone of the Berlin airport project took 15 years). Plan iteratively -- per work package or phase -- and throughout the project.

4. Extended project schedule. Just because the project schedule is met doesn't necessarily mean the budget will be met as well. On the other hand, it is highly likely that if the project schedule is not met (for example, due to a project time extension), then the project budget will be blown thanks to additional costs that may pile up, since the project team and resources will be needed for longer. 

Mitigation: Manage the project time and schedule well. Focus especially on the tasks on the critical path, which can have the most impact on both project schedule and costs. If you get asked to extend the project time, explain to your stakeholders that this probably will cost more. Remember the scope-time-budget project triangle. Time is money!

5. Improper buffer planning. If you don't plan (or plan improperly) for a budget buffer, the smallest deviation in scope or schedule will cause an overrun. 

Mitigation: A budget comprises estimated cost and some contingency. Plan the contingency for unexpected scope changes, unusual weather changes or possible problems with suppliers. Consider a buffer for the costs that cannot be accurately or predictably estimated. Some of the cost estimates will be more accurate than others -- for example, commodity prices will be more predictable than labor costs for a specific service.

6. Improper resource planning. Labor resource costs could be one of the project's biggest expenses. If the project lacks labor resources, a later labor force acquisition will be an unexpected project cost. It can also mean a higher cost since the contracting conditions might not be the same as when initially planning the project. Similarly, resources allocated in excess will mean unnecessary allocated costs, plus unnecessary blocked resources that could have been useful on other projects.  

Mitigation: First plan the scope, then the required work to be done, and then the related assumptions, dependencies and risks. This will facilitate a better understanding of the work needed to be done and hence will help better assess the right equipment, amount of resources and required skill sets.

How do you manage costs on your projects, and which measures do you apply to avoid cost overruns?

Great Time Management Is in the Details

| | Comments (1)
Voices_Bernadine_Time v2.png

Bringing together all the aspects of a project -- including stakeholders, team members, software tools and project requirements -- is just the beginning. Once we gather all the pieces of the project, we cannot sit back and relax. Properly controlling a project hinges on using time management skills to see it through to the end. And those skills consist of these three types of actions:

Reactive. There will always be an aspect of the project that needs to be tended to: risks and issues that may need near turnaround resolutions or disparate interests of team members and stakeholders that need addressing. But it's how we've set the stage for our project that will help us steer the project to the finish line, so allot some time to plan for issues to come up. Always be aware of how your surroundings and other resources may affect your project and how they can be of value at another point. For example, when your project is heading into a critical situation and you have no resources that can help, have a contact at the ready who may be able to get an immediate resolution.

Co-active. This element entails taking collective action toward correcting an off-schedule project. While we set out to have a process for every action, somewhere along the line, the schedule starts slipping or team members aren't reporting bottlenecks or bad news in a timely fashion. In these instances, reset the tone of your project control. My technique is to keep the scope constantly visible, usually by making sure the agenda has it displayed. However, I didn't do this on a project years ago. The developers were making ongoing enhancements to the software, ones that would be very useful at a future point. Yet they were very off-scope. The co-active measure was to pull back on the enhancements and redefine the scope to get it to what the sponsor originally requested. I did so by meeting with the sponsor and development team manager and reviewing requirements from the standpoint of: 

  • Which elements are most important
  • What doesn't have to be implemented immediately
  • What has been designed that can be kept 
  • What can be released in a quick turnaround
Proactive. But what if a project has components that are not fully defined yet? This is a situation in which we're not reacting to the existing project or controlling project issues, but instead considering the future: possible risks, another project's potential impact or information a stakeholder may want. Here I would recommend actively anticipating what may be helpful that has not yet been discussed. And this consideration can be addressed perhaps as an earned value chart, a report outlining project enhancements for future work or something as simple as organizing a meeting with sponsors to ensure there are no new impacts on the rise.

Are there any aspects to managing your time in a project that you see as helping to bring the project to a smooth close?

What Race Cars Can Teach Us About Projects

| | Comments (3)
My last post on when to pull over a project to the side of the road generated much action on the Voices on Project Management Twitter feed. Here, I'll expand on that theme by highlighting the similarities in the makings of a race car and a successful project.

Today's race cars are a marvel of engineering and performance. They achieve these results while being extremely complicated and operating in harsh environments. However, to the spectator, racing appears to happen easily and naturally. When we see a race car whiz by, we don't see the many hours of planning that go into achieving both high speed and durability. 

Therein lies the parallel between race cars and projects. As project practitioners, we need to consistently ask ourselves whether our "project race car" is ready and able to win the race. This includes design and preparations before the race as well as vigilant monitoring of performance. 
Here are four essential components of a "project race car" that have to be well engineered and constantly monitored for your project to be a success: 

  1. Engine: At the heart of any race car is its engine. The engine provides the power to move the car down the road to the finish line. Great effort goes into the design, operation and monitoring of the engine to extract the maximum horsepower. The engine is similar to the project's business case. It also serves as the "horsepower" to drive the project to its desired outcome. If your project business case experiences events such as new or changed assumptions that cause it to lose momentum, then your project will start to fall behind and potentially stop. As with an engine, good business case design and constant attention to its performance is essential to project success. 
  2. Chassis: The power from the engine of a race car is transferred to its chassis, or structural framework, to propel it safely down the racetrack. The enabling infrastructure of the frame, wheels, suspension, steering and aerodynamic body all contribute to a smooth, fast ride. The same can be said of the methods, processes and tools that are a critical part of any project. These project management essentials must all be employed to work together in harmony for the project to move down the road. Could one imagine starting a race without all of the wheels on the car? Unfortunately, many projects do so without having the right fundamental elements in place. 
  3. Fuel: On a race car, the amount, type and consumption of fuel is a key factor in its ability to win a race. Each year the governing bodies of racing organizations work to tighten regulations around fuel to both achieve higher engineering performance and reduce environmental impact. Failure to select the proper type and amount of fuel can prevent a car from making it across the finish line. Many times I have seen project reports in which the overall status looks favorable but there are unstaffed roles. This lack of resource "fuel" can also prevent a project from getting to the finish line.    
  4. Driver: Even with the most advanced race car, it takes someone to help start it and confidently move it forward at the fastest but safest speed. In addition, the driver must also constantly monitor engine, chassis and fuel state as well as external conditions that will affect the pace of the race car. For projects, the driver is the project manager. The project manager must effectively start and guide the project, while also monitoring and adapting to external conditions such as other project dependencies and risks. 
How many times have you started a project "race" though one of the previously mentioned components was missing? What is the most frequently omitted element in the "project race car"?

For an insider look at car racing, read about a recent keynote speech on Formula One by Mark Gallagher at PMI® Global Congress 2014 -- EMEA.

Getting Documentation Right

| | Comments (1)
Documentation is an important aspect of a project manager's job. We document to keep us aware of status on projects. We use it to stabilize spending and keep a paper trail of events and circumstances. So, what should you capture and how should it be maintained? Here are a few tips to make sure you're capturing usable documentation.

  • Know your source. Having the information helps, but being able to backtrack to determine who provided it -- and thus its worthiness and validity -- is even better. This is important in the case that information comes into question later. For instance, if you receive a pre-defined budget for your project but then are given another amount, a senior source with oversight over your project can help validate the original amount. Be sure to have that contact's information and even a backup source in case that source moved on.

  • Have clear, concise information. Lessons learned will tell you that communication is key to getting information correct. As much as possible, try to make documentation clear, so the knowledge transfer process goes smoothly and you, team members and stakeholders are able to follow it. Include wording that easily links to follow-up information or shows there is a continuation to a document.  

  • Use a repository. Make sure to keep documents in a secure location to be able to recall them when needed. Whether you file documents by projects, size or funding amount, at the very least have a system for filing. Have some type of dated system for knowing what is the most current file or selected information. This will help to determine if the information is no longer useful.

Now that you know how to maintain documentation, we'll review which documents should be retained in my next post.

 What are your must-have tips for documentation on projects?
One of the regular challenges I hear coming from the project management community is the idea that our organizations are setting unrealistic goals. This is a tremendous challenge because setting unobtainable goals can lead to project failure, low morale and a culture of insecurity. 

It's vitally important to spend time working with our project management offices (PMOs) and sponsors to develop realistic timelines and goals that are achievable in the short- and long-term. Why? Because this is going to help maintain motivation throughout the project as each milestone is obtained. Additionally, it will help you communicate progress more effectively to your sponsors and gives you the capability to set clear, reasonable expectations at the start of the project. Here are three ways you can set better goals that motivate your teams, sponsors and stakeholders:

  1. Ensure clarity of project goal. To effectively set proper goals for your team, you need to make sure that your goals are in line with the project's objectives. Too often projects go astray because the project's goals aren't clear or don't align with the business objectives of the parent organization. This can be managed by making sure that you clarify the project's goals at the very start. For example, set up a meeting with your sponsor or executives to talk about project objectives, how they will be measured, and the sponsor's role and responsibilities. This simple step ensures that you have clarification and can work with your team to set goals that are in line with sponsor expectations. 
  2. Take a short and long view of the project. It's often too easy to look at the end result of a project and say that is the only goal that matters. This can throw off your team and demoralize everyone involved, because if you are dealing with a project that can take years to complete, there is no sense of accomplishment, even when you have completed a major milestone in the project's life cycle. That's why you need to set short- and long-term goals. The short-term goals will do two things: First, they help your team members stay motivated and drive progress by giving them an occasional sense of accomplishment. Second, they give good insights on whether the project is on- or off-course, making it much easier to adjust the schedule and plan accordingly. 
  3. Communicate. Everything in project management comes down to communication. In setting goals for your team, you need to communicate consistently. A successful communication strategy focuses on clearly relaying the project's objectives and goals and how those support the organization's mission; explains how the short- and long-term goals relate to each other; and allows you to maintain control over expectations. 
While it isn't possible to control every variable on every project, a project manager can make great strides in team performance by using goals to set proper expectations. 

What helped you set proper goals in a recent project?

Read more about PMOs and their impact on strategy implementation in PMI's Strategic Initiative Management: The PMO Imperative.

7 Steps to Project Planning Acceleration

| | Comments (4)
What's a reasonable amount of time to devote to planning a project? I use this rule of thumb: If it is a low-uncertainty project (i.e., we've completed another with similar conditions in the past, with known technology and firm assumptions), devote at least 10 percent of the expected duration of the project to planning it. If it's perceived as a high-uncertainty project (i.e., one with new technology, new approach, uncertain conditions), devote at least 20 percent.

But let's face it. Often, organizational pressure will not allow us to devote that much time to planning. So is there an approach that lets us reduce planning time but still do good work and come up with a complete, useful plan? 

Many organizations I've worked with use a project planning acceleration workshop (PPAW). This is an organized, closed-door, multiday session with the whole project team to focus exclusively on producing the project plan -- something that usually takes several weeks, completed in a few days' time. There are different ways of organizing such an event, but I usually follow these seven steps:

1. Plan the plan. Share with team members all of the project's background information. Send invitations with enough lead time and clearly state the session's sole objective, which is to produce a solid project plan. I often kick off the session stating that once we are finished, we will have a project plan that is roughly 75 to 85 percent complete -- and that we are going to accomplish this in a very short period of time. Therefore, total commitment is required from all participants.

2. Set the stage. What you want is an environment conducive to teamwork without distractions. Secure a room to host the workshop, preferably outside of the office. And don't forget to include a lot of food and beverages for the duration of the workshop. When people are tired, food helps!

3. Define the agenda. Depending on the complexity of the project, different workshop durations will be required, but three days is adequate for most projects. I often use an agenda that looks like this:

  • First day: Devote the morning only to the human elements of the project -- for example, for introductions and team integration activities. It'll set the stage for the rest of the workshop. In the afternoon, analyze the project background and produce a thorough project charter that includes scope statement, time and cost constraints, major deliverables, key stakeholders, expected benefits, restrictions and assumptions.
  • Second day: In the morning, develop the work breakdown structure (WBS). Make the whole team work on defining the major deliverables and then break into smaller groups to further decompose these major deliverables. Produce the project's schedule in the afternoon.
  • Third day: The planning elements needed for your project might vary, but I usually devote this day to producing the budget, a roles and responsibilities matrix (mapping the team members to work packages on the WBS), a key resources plan and a risk management plan. 
4. Use collaborative working techniques. Don't just project steps on a screen; make team members work together. When producing the WBS or the project schedule, use the participatory cards on the wall (COW) technique. For the risk management plan, brainstorm together to identify risks and ask participants to pin different risks on color-coded charts according to their assessment of probability and impact. 

5. Document everything. Assign someone in the team to document everything produced. You may use Post-its to draft the WBS or the schedule, but these elements need to be recorded formally for when the project starts. 

6. Assign tasks for completion. After the workshop is finished, the project plan won't be completely finalized. Usually certain parts need more research or analysis. Assign specific team members to complete outstanding pieces and establish a deadline for completing these elements that were initiated at the PPAW.

7. Kick off the project. Once the project plan is deemed completed, host one more session to make a final review of all the elements, especially those that needed further research. Combine this activity with a formal project kick-off meeting -- the end of PPAW and the beginning of your project.

In my experience, when a team is co-located and completely focused for a specific period of time to create a plan, it yields better results.

Have you ever run a PPAW? How has it improved your project?

3 Techniques for Breaking Constraints

| | Comments (0)
In my last post, I wrote about the importance of a project schedule plan and the fact that a project schedule is generally constrained by various factors. In this post, I'll take a deeper dive into the three techniques that can be applied to address resource and time constraints.

Resource leveling

This technique can be applied to a project's schedule plan when the project is facing resource constraints or when you need to allocate resources consistently and most effectively throughout the life cycle (e.g., all resources utilized at 100 percent capacity by project completion). You'll need to apply this technique when resources are available only for a certain time or when you have resources over-allocated in parallel project activities.

The basic idea behind resource leveling is to recognize tasks, priorities, dependencies and constraints. Tasks with the highest priority will be scheduled first. Others, depending on their dependencies and constraints, will be moved for later or assigned other resources available during this time.

Logically speaking, resource leveling is applied in this order: 

  1. Develop the schedule.
  2. Consider work tasks, dependencies and constraints.
  3. Identify the critical path of your project schedule.
  4. Allocate resources.
Once you have identified resource bottlenecks and over-allocated or under-utilized resources, set task priorities and apply resource leveling. In some cases, resource leveling can lead to critical path changes -- for instance, if you have to extend the duration of a task on the critical path, due to the reduced availability of a critical resource.

Schedule crashing

This is a schedule compression technique for dealing with time constraints without sacrificing project scope -- for example, when you have to meet a hard deadline for one of your project's deliverables.

This technique focuses on the tasks on the critical path. Shortening them reduces the total duration for meeting a given deadline or milestone. And delivering a project in its entirety, with no scope change, in a reduced time can only be achieved by increasing or improving the resources allocated for that task. 

As an example, let's take a software project aimed at creating a new system, and migrating functionality and data from an older system. You could reduce task time by allocating more programmers to develop in parallel the functionality of the new system. Similarly, to shorten the data-migration time, you could replace a regular computing machine with a more powerful one.

Be aware that crashing the schedule will generally increase costs. And sometimes, there will be tasks that will have the same duration, no matter how efficiently they can be performed (e.g., monitoring the stability and reliability of a component for a fixed time). 


This is another schedule compression technique that can help reduce project time without changing the scope. The focus of fast-tracking is on expediting certain tasks by overlapping their execution, despite their dependencies. 

Let's take the same software project as an example. Chronologically reversed, programming the new functionality (task number one) depends on designing it first (task number two), which depends on a gap analysis task (task number three). By applying fast-tracking to these three tasks, instead of executing the tasks in a sequence, you can overlap them. You can start the design (task number two) in parallel and lagged with the gap analysis (task number three). Similarly the programming (task number one) will start lagged while the design (task number two) is in execution.

Fast-tracking is one of the most-used tactics to deal with time constraints, but it does have a few downsides. By not waiting for the complete results of preceding deliverables, fast-tracking could lead to delivering lower quality or even reworking some tasks, which can result in additional costs and delays. The project environment can get very dynamic with tasks conducted in parallel. This can be a challenge for project managers, who might lose sight of the bigger picture or get overwhelmed with managing overlapping activities.

What is your experience with these techniques? Which do you think is most effective?

Keep the Schedule Plan Strong -- and Constraint-Free

| | Comments (0)
The project schedule plan is probably one of the most important project management assets a project manager has to develop, maintain and manage throughout a project. Why? Because compared to other planning documents -- such as the resources plan, costs plan or risk management plan -- a project schedule will generally have widespread visibility within the project's environment and among stakeholders.

For instance, your project sponsors will want to see your project schedule and understand whether you are on track to deliver it on time. The beneficiaries of your project will want to see it to understand your next deliverables or key milestones. Your core project team will seek it out to find out how work activities are planned and relate to one another, and how resources are allocated. And, probably most important, you as the project manager will need it to be your map throughout the project, guiding you to drive the project to its target. 

Now, if your project schedule is incomplete or flawed -- for example, it's missing work tasks or it features wrong dependencies between project tasks -- you will most likely steer your project into a wall. And even if you put everything right into it (i.e., all work activities, the right durations, right resources assigned, right dependencies), that still might not be sufficient for a successful delivery. That's because, as you know, a project schedule is not a linear sequencing of work tasks that perform exactly as initially planned. 

In addition, your project schedule will be subject to the project's challenges and constraints, such as resources scarcity, work overload, aggressive milestones or delays. It's these unexpected or imposed factors that will constrain your project schedule and demand that you react quickly, applying various tactics and techniques, to adapt the project schedule and make it ultimately work.

There are several techniques that can help in analyzing, adapting and improving a constrained project schedule. Among these, three stand out for their effectiveness:

  1. Resource leveling, to be used when you have resource constraints or are aiming for more efficient and effective resources utilization 
  2. Schedule crashing, for reducing tasks' duration by applying multiple or better resources to the same tasks
  3. Fast-tracking, to reduce the project duration by overlapping tasks that otherwise would have been sequential and dependent on one another

In my next post, I'll dive deeper into what these three techniques are, when to apply them and how to do so.

How do you manage constraints to your project schedule?

Setting the Stage for Order

| | Comments (0)
In a project, you and your team may face what seems to be an endless mountain of tasks and deadlines. You need to provide clarification and direction. And to do so, you'll need to prioritize work as you build a project schedule. The good news is, to do so, there are really only two things you need to know about a task: 

  1. What is due? 
  2. When is it due?
If you know what is due, you can determine estimates on the work and think about what indicators are involved in getting the work done. These indicators may include:

  1. Funding. A low budget usually means a small work effort is expected. A higher budget will allow for more effort and charge-outs. This means you may become responsible for purchases and expenses that will require an authorization above and beyond your own. 
  2. Resources. If your project involves other people or outside vendors, you need to consider whom you may need to retrieve something from. For example, if data is required to get the work done, factor this into the project's effort. Your timing to receive it and the timing you will need to respond to what you receive is important. Global projects and virtual teams as well as a geographical scope require technology advances. So remember to factor in costs for equipment, connections and any possible barriers that need to be handled.
Next up is the "when is it due" question. The way you structure the project, such as a large versus a small effort, can help to determine timing. And to help you figure out timing, consider:

  1. Known risks and issues. These put a constraint on timing. So, being aware of when the project is due will most likely dictate if a certain task can be done in a certain timeframe and if something else can be pushed slightly to another timeframe. Be cognizant that unknown risks and issues could cause further problems and delays.  
  2. Lessons learned. Previous lessons learned provide information on how other projects with similar indicators fared.
Prepare a chart or checklist with the significant indicators that make it possible for you to get the project done. Budget, the team (resources), complexity of the work to be done and due date should be columns in your chart. Rank each according to its priority, using a scale of 1 to 10, for example. Demonstrate what the ranking means and what constitutes that level of rank. 
Once you have your chart prepared, share it with anyone who may need to rely on it. If a stakeholder or team member comes to you questioning work and has workload problems, disclose your chart. This will lessen a helter-skelter approach to the project work. Finally, have support for your decisions. Your manager or director must support your system for prioritization if it is going to work.

How do you prioritize work?

Multi-Project Schedule Planning, Part II

| | Comments (0)
In my previous post, I set the stage for what it means to manage a project in a multi-project management (MPM) context.

In this post, I will share some best practices in the form of do's and don'ts that I hope will provide you with some basic guidance on how to steer and manage a project in an MPM environment.

Here are a few do's:

Be present. First and foremost, your project needs to be represented by you as a project manager during the MPM community's key shared events. There will be status meetings, where all project managers will report their progress, achievements or issues. There will be decision meetings, where overall decisions will lead to a shift in gears and put projects on new tracks, or where projects' priorities will be reassessed. You'll have to be there to understand the implications of these changes to the MPM environment and contribute to MPM developments.

Show commitment. The last thing your counterparts want to see from you, in a complex project environment, is the team committing for a milestone or deliverable and then not seeing it through. Show commitment and responsibility for your part of the project and demand the same from your counterparts. 

Shed light. When odds are against your project and your commitments are threatened, make this visible in the MPM environment and shed light on the underlying impacts with strong communication management. Failing to communicate MPM-relevant results could generate ripples in related projects. For example, if you don't communicate on time a slight delay in the MPM project, this withheld information could cause huge delays in related projects.

Request orchestration. Request that the MPM project's overall coordination/orchestration is done by an independent person, a person other than the project managers of the underlying sub-projects. This is a prerequisite for attaining common project goals and avoiding project conflicts, due to the various project interests that are put in place.

Inform your team. Since your project team members will mainly be focusing on the project's inner scope, keep your project team informed about developments in the related MPM projects.

I recommending avoiding these don'ts:

Silo planning. In an MPM setup, where scope, timeline or resources can overlap, silo planning can jeopardize your project and the correlated projects. Plan jointly and agree on high-level planning with your MPM counterparts. 

Adversity to change. To respond to changes external to your project, which can be critical for the overall projects' success, your project and stakeholders will have to be resilient to change, not adverse to it. Inform your stakeholders and enhance your change management process to allow changes that support and facilitate overall goals.

Disregard risks. When you have hard dependencies on or with other projects, do not underestimate or neglect managing risks. A tiny risk in your project can have significant impact on the related projects. Identify risks, quantify their occurrence probability and impacts, plan responses and share your risk management plan in the MPM community. Demand the same from your MPM counterparts.

Information overload. Although on one hand it's critical that your team is informed about what happens in the related projects, information overload from the MPM community can disturb your team's focus. Filter the information from the various MPM project teams, and share the significant information within yours when the time is right for your project.

Sluggish steering. While multiple forces from the MPM setup might influence your project course, do not permit your project role and influence to fade out. You are still the project manager; you are still the one holding the reins of your project.

Do these do's and don'ts apply in your multi-project management setup?

Getting Out of Trouble

| | Comments (3)
Project trouble can hit from a blind spot, even though you tried as much as possible to prepare for issues. You did a risk analysis when you took the project on, and even tried to be ready to mitigate unknown issues.   

As I advised in my previous post, do an assessment to determine the problem. Figure out what needs to be fixed, or if the situation is even fixable. If the project seems to have reached a point of no return, here are some tips on how to pull it out of trouble:

  1. Seek out your sponsors. They should be the source to go to when trouble arises. Not only is it likely they will have encountered something similar in the past, but they can also provide additional budget funds, more resources or reinforcement for areas in conflict.
  2. Consult with your team. Bring everyone together, discuss the problems surrounding the project, and begin to discuss counteraction and next steps. Steer away from blame and trying to determine who is at fault. Beware especially of ganging up on the customer. Team members may want to take the position that it's the customer's problem, not the team's. But be clear that the point of getting together is to determine how to solve a problem project, not pass it off as someone else's fault. Instead, gear questions toward possible solutions and the support needed to achieve them. 
  3. Rely on backup and supporting information. Most likely, you will have monitored risks and issues all along and kept a good repository on your project. If so, you will be able to locate the exact information that helps address your problem. For example, you may be over budget because equipment purchases ate even beyond what your contingency allowed, and now a project sponsor or customer may be questioning the overrun. You should be able to pinpoint the authorization you received to make that purchase. 
  4. Enlist outside resources, if needed. Lessons learned or a fellow project manager could be consulted for knowledge transfer and experience. You could even call in an outside contractor for a specific need. 
  5. Remember that a halt is an option as well. Most times, this is seen as negative, and the project is considered a failure. But that is not necessarily the case. Sometimes, halting the project is the necessary solution, and it doesn't have to have horrific implications. If it isn't halted, the project could accumulate astronomical costs. The trouble could consume the project to the point where it would need to be shut down. A halt can also help you assess if the project is still meeting objectives (which could be the source of the problem). Stopping the project in its tracks could help you to determine if you need to redirect funds and/or resources. 

Finally, keep in mind that not all trouble devours all. Before panicking, calmly look to areas that will guide you to a solution. You may even find your project is more sound than it seems.

How do you confront trouble on your project?

Work Before the Work Plan

| | Comments (0)
While reviewing a project work plan this week, I thought back to the first generation of work-planning tools. I marveled at their ability to mechanize manually arduous activities, such as progress calculations and schedule charts. After using these tools on a few projects, I felt supremely confident about creating a work plan and managing a project of any size.

But as I became more proficient at using them, I found myself struggling to make the work plan match what was actually going on with the project. After much frustration, I spoke to a senior project manager. She suggested that before even touching the tools, I needed to rethink my approach to work planning. Here are some of her tips that I continue to employ today:

  1. Design the work plan around the core outcome of the project. In my haste to become adept with a work-planning tool, I neglected to consider the project's core outcome -- and how it would be delivered. Before starting to build a work plan, you need to determine whether the project's primary outcome depends on the completion of tasks, orchestration of resources or creation of certain deliverables. For example, if the project objective is to implement a newly defined process across multiple teams, consider organizing the work plan around teams and their needs. 
  2. A project's complexity can affect your progress-tracking method. A classic mistake project managers make is employing a progress-tracking method that's not in sync with the complexity of the project. In my experience, projects with low complexity, for example, are better served with a straightforward percent-complete scheme. But I have noticed that a project with added complexity (i.e., interfaces, dependencies, resource mix) requires a more robust tracking method, such as earned value, to ensure a precise measurement of progress. Aligning the progress-tracking method to the complexity of the project also helps you avoid unnecessary effort in reporting project progress.
  3. Capture and use resource commitments. The senior project manager who advised me could not say enough about the benefits of this. She observed that by not accurately capturing to what degree resources were dedicated to my project, I was creating an overly optimistic project schedule. And my project was running late as a result. 

I recommend capturing a fixed commitment -- that is, the amount of hours by resource per week. This accounts for even those resources that, by the nature of their labor contracts, can only devote a certain number of hours to the project. It also highlights the capacity these resources have to work on other projects. If the capacity is a set amount, you can quickly determine a more accurate project schedule.

What are your tips for getting off to a good start with work planning?

Multi-Project Schedule Planning, Part I

| | Comments (1)
Projects are rarely planned and executed in isolation. In general, they have external dependencies on activities, tasks or deliverables outside the project's reach. Managing tasks and dependencies that spread across several projects, which are not necessarily part of a program, creates a multi-project management context.

For instance, say you are managing an IT project, delivering a software application. Many of your project tasks will be conducted within the project's boundaries and with the full control and ownership of your project team. Nevertheless, your project has dependencies on a software component, developed in parallel by another team within the same enterprise, yet as part of an entirely different project. Your project will have to wait for the other team to finish and deliver its component to deploy and test your software application. Since the two projects have phases and deliverables dependent on each other, their project schedules will have to be correlated.

Managing correlated schedules requires a different approach. In a single-project context, a project manager plans the schedule, giving consideration to the project context, the work to be carried out by the project team, assumptions, risks, and the tasks' internal and external dependencies. This is more or less a silo approach, where the external dependencies rely on deliverables and not on the project phases or cycles in which they are produced.

In a multi-project management context, the project managers involved, or an overseeing multi-project manager, will have to reach alignment across the projects in several aspects, including:

  • Aligning project stages and deliverables depending on their interrelated dependencies
  • Reaching agreements and locking down commitments for respective conditions, such as the quality of deliverables, meeting deadlines required for the touch points between projects  
  • Sharing risks and planning required measures together, in case one project negatively impacts the other
Let's go back to our previous IT project example, and how alignment could happen. The two projects start off independent of each other. Then they can have touch points during the requirements analysis and scoping phase, when your project team will analyze and hand over requirements and product specifications to the other team. Then the two projects will meet again during a joint testing phase, when both project teams will deploy and test their application components integrated together. Finally, the two projects will meet again during the go-live deployment, when the rollout of one project will not be complete without the rollout of the other.

The more touch points the projects have, the more complex their schedule planning will be. The stronger their dependencies, the less flexibility you will have when planning your project schedule. And the more relevant the other project is for your organization, the less planning flexibility and schedule control you will have on yours.

The situation gets even more complicated when your project depends on three or more other projects, which have different schedule plans, business criticalities and even project management approaches. For instance, your project is conducted in a waterfall methodology, and it's dependent on another project following an agile approach. It can become quite challenging aligning your waterfall schedule to the iterative and dynamic schedule of the other project.

What is your project scheduling experience with dealing with multiple projects that depend on each other?

Essentials of Successful Project Schedule Planning: Part III

| | Comments (0)
In past posts, I covered five steps for setting up a schedule planning framework and seven basic tips for building a project schedule.

In this final installment of this series, I'll discuss 10 common pitfalls of building a schedule on any project:

  1. The silo approach: Avoid developing the schedule in "silo" mode -- that is, without input from key stakeholders or subject-matter experts that can validate and confirm the schedule's content.
  2. Inappropriate tasks decomposition: When decomposing work in tasks, avoid an overly detailed decomposition or under detailed decomposition. In my experience, each task should not be shorter than two days and not longer than two reporting periods (typically two weeks). A task of this length is generally explicit, focused, actionable, assignable and traceable. 
  3. Too many milestones: Limit milestones to significant project events or decisions -- for example, the project start, completion of major deliverables or phases and the project's end.
  4. Overly ambitious schedule: Everyone wants to please the customer, but an aggressive schedule can have the opposite effect if unrealistic deadlines are continually missed. Instead, aim to exceed expectations by delivering the project in a realistic timeframe, with solid execution. If you inherit an overly ambitious schedule, you could "fast-track" (i.e., make work parallel) or "crash" the schedule by assigning more resources to reduce task duration.
  5. Loops: A project schedule is not a flowchart, and time cannot flow in reverse. Therefore, loops, a circular task dependency, are not possible or validated by most project management scheduling software. Do not confuse loops with iterations. Iterations of tasks --such as design, implement and deploy -- are allowed on a project schedule.
  6. Danglers: These are the dependency links between tasks. Only one task will have no predecessor (the project start task) and only one will have no successor (the project end task). All the other tasks should have a successor and predecessor.
  7. Confusing tasks efforts with schedule time: Don't just ask team members: "When can you complete this task?" Instead, ask for the estimated effort to complete the task in labor hours or days. Then, transform the effort into work periods (the work days the team member can carry out the task) and map this to the project calendar (considering business days, holidays and vacation periods). 
  8. Allocating schedule buffer instead of effort buffer: Don't allocate buffers to a certain schedule time. Task estimation is a three-step process: effort, duration and required calendar time. Allocate buffers primarily on a task's effort and not on the overall required calendar time.
  9. Depending on overall buffers: Avoid relying on sweeping buffers, like the classic "20 percent." When assigning buffers, consider the project-specific risks (for example, unfamiliar technologies), the experience of the project team and non-project related factors, such as resources allocated to parallel projects or team members' involvement in non-project activities.
  10. Wrong tasks on the critical path: Project management tasks, effort estimation tasks and other schedule planning activities should not be located on the critical path. They have nothing to do with the actual project work tasks.

How do you overcome these pitfalls, and what other schedule planning difficulties have you faced?

Head Off Problem Projects

| | Comments (2)
We've all seen the signs a project is about to blow up — a schedule goes awry, a budget exceeds its tolerance threshold. To prevent this, consider taking a few measures:

  • Secure executive support for major issues. Initial project documentation, such as a project charter and communications plan, will classify your project sponsors and champions, their roles and responsibilities, and escalation procedures. Rely on that, but also position yourself for frequent project status meetings with executives. 
  • Keep communications with sponsors and key stakeholders at a level that allows you to reach out to them when you may need them.
  • Be aware of your project environment at all times. Regularly review project plans against where you are and what's planned to come. It will help minimize the risk of an issue arising when you least expect it — a resource pushed to the point of no return, for example. 
  • Look for lessons learned. Review the project history for potential concerns you may want to monitor and document in your risk log. Meet with other project managers in and outside of your organization to learn about pitfalls they may have encountered and how they handled them. 
Prevention requires preparation, listening and awareness. As you interact with your team, your sponsors and other project managers, be sure to listen and look for pain points that warrant investigation. 

In my next post, I'll talk about recovery steps when facing a troubled project. For now, please share what you do to prevent troubled projects.

Essentials of Successful Project Schedule Planning: Part II

| | Comments (0)
In my previous post on project schedule planning, I referred to a five-step approach to setting up a schedule planning framework.

In this post, I offer seven tips on creating a schedule for any project:

  1. Focus on action. A project schedule is all about how deliverables will be produced. So after you break down work packages and deliverables, use active verbs to describe the smaller work tasks. For example, say "design webpage" instead of just "webpage designed."
  2. Keep tasks simple and compact. For a clear, clean project schedule, make task names short. If necessary, go into more details in an appendix or separate document to elaborate on each task and its outcomes.
  3. Create context. Also in a separate log, briefly document assumptions and constraints that accompany tasks. This helps in sequencing, linking and managing the tasks. For instance, if you know that a task needs to be executed in a certain timeframe, then you can better link, sequence or parallelize tasks.  
  4. Diagram. A visual illustration of the task sequencing and relationship will help the team understand the task dependencies and anticipating when these dependencies should kick in. Additionally, a visual breakdown can help identify tasks that can be done in tandem (i.e., those that have no dependencies).
  5. Use the critical path. Apply information gleaned from the critical path to the schedule. The critical path is most helpful in monitoring delays or identifying opportunities to accelerate the schedule. If a task located on the critical path slips, the project can be delayed. If a task on the critical path can be shortened, the project schedule can get shorter. If the critical path's duration exceeds the project deadline, then reduce scope, reassess durations, improve estimates or increase team resources. 
  6. Assess duration properly. When estimating task duration, distinguish between effort, duration and required calendar time to complete a task. The effort relates to the actual work required to complete the task (i.e., How many hours?). The duration refers to how many work periods are required to complete the effort (i.e., How many work days?). The required calendar time means mapping the work days on a calendar that includes holidays and vacation periods.
  7. Combine duration methods. Related to the sixth tip, combine multiple methods to assess duration. Take into account estimations from past projects and apply parametric estimation. For instance, if you use the three-point estimation (i.e., pessimistic, optimistic and most likely), find the theoretical estimation based on current expectations — but in addition, incorporate estimates from similar past tasks or projects.
What other tips help you when building a project schedule that can apply to any project?

Three Reasons to Dim Project Stoplights

| | Comments (4)
Hardly a project status report goes published without at least one stoplight indicator. As the name suggests, stoplight indicators show the status of key project progress measurements: green (good to go), yellow (use caution) and red (stop or danger ahead).    

In recent projects, I have noticed recurring instances of "stoplight overkill." Project status reports now include all manner of stoplights, such as how the last status meeting turned out or the happiness level of every single customer group. In fact, I have even seen a stoplight indicator that, through a complex calculation, was intended to show the aggregate status of 40 stoplights. The colors on that report made my head spin.

Beyond avoiding a headache, here are three major reasons why project managers should limit stoplights:
  1. Stoplights are not progressive. Project stoplights typically have only three indications of status. They can't show a range of progressive tolerance, trends or rates of change. For example, a yellow stoplight can be overly optimistic if the value for that stoplight is just shy of the range for red.
  2. Stoplight bands mean different things to different measurements. Stoplights break down into bands of tolerance ranges. For example, zero to 5 percent variance would be green, 5 to 10 percent variance would be yellow and above 10 percent would be red. The problem is, project measurement indicators might not follow a common range. For example, how realistic is it to measure customer satisfaction with the same band as test case validation? While test case validation might make sense at 7 percent, it would be discouraging if just 7 percent of your customers were happy with your project.
  3. Stoplights can be "gamed." A major vulnerability of project stoplights is that they can be manipulated by project managers and sponsors when either wants to defer an unfavorable status. Despite the actual value of the project measurement, the project manager or sponsor will leave the stoplight to a green (favorable) value. This "gaming" of project stoplights usually precedes the inevitable -- rapid acceleration of stoplights to a red (danger) value when hidden details are discovered. 
I favor more progressive and consistent modes of status presentation that indicate position, direction and pace. 

For example, use a remaining budget marker to show the position of budget against a broader range of tolerances. For deliverables, you can show a scatter plot of projected and actual completion dates to reveal pace and true progress. Highlighting customer satisfaction on a timeline is a good way of showing the impact of a project on a sponsor's business.  

What do you consider the limitations and dangers of project stoplights? What alternate methods have you used on project status presentations? Share your thoughts below along with your Twitter handle, and Voices on Project Management will publish the best response as a blog post.

Essentials of Successful Project Schedule Planning: Part I

| | Comments (1)
Technically speaking, the project schedule is a key project planning component. But practically speaking, simply creating a project schedule does not guarantee project success. Project success requires the project manager to plan out a reliable, comprehensive and realistic schedule.

The following three-pronged approach helps in creating such a schedule: set up a schedule planning framework, master schedule basics and run the project avoiding the classic schedule planning pitfalls.

In this post, I will shed some light on a simple schedule planning framework. Effective schedule planning boils down to five basic steps: 

  1. Plan. Identify which sources and resources will provide the project schedule information, such as the scope baseline, scheduling takeaways from similar previous projects and subject matter experts. Select the appropriate software tool to manage the schedule. This could be a standard project management tool used by your company, or it can be one you have selected considering your project's level of complexity, reporting automation needs and team collaboration requirements.
  2. Develop. Break down the work packages and deliverables into actionable tasks. Identify key milestones, such as completion of major deliverables or project phases. Sequence tasks logically, depending on their execution order and dependency on other tasks. Match team members to each task with their corresponding skills. Assess task efforts and all project time based on historical data from a similar project, or using techniques such as the Program Evaluation and Review Technique (PERT).
  3. Validate. Work with subject matter experts to review and validate the developing schedule.
  4. Follow through. After creating a baseline project schedule, track the completed tasks and achieved milestones. Developing a project schedule is not a final destination -- it has to be maintained.
  5. Adjust. You will rarely finish the project by following the exact schedule plan you began with. Adjust the schedule as you go by exploiting the opportunities that arise (such as fast-tracking activities or finishing work earlier, if possible), or taking corrective actions when faced with delays or unexpected activities (such as enlarging the team or "crashing" activities).

What are your must-do steps when creating a project schedule? What scheduling framework has been successful for you?

Decomposing Requirements for Tangible Project Outcomes

| | Comments (1)
Delivering scope or fulfilling needs on a project is not always equivalent with adding value. In my opinion, a project adds value to an organization if its deliverables add value. 

Many project managers approach the project in a delivery-oriented fashion. They plan for, work against, and monitor and control the project's work through deliverables. Delivery-oriented project managers make the scope's outcome tangible in order to fulfill the project's goals. 

The first step to incorporating this project planning technique is to understand what a "deliverable" is. "Deliverables" are concrete and discrete artifacts of a project's outcome, such as products, functionalities, features, documents and plans. They can be obtained by "decomposing," or breaking down, the project's requirements in smaller, more manageable components. 

As you decompose requirements, keep in mind that you can structure and manage the project deliverables in various ways. Some of the most common approaches for different types of organizations include:

  • Spreading deliverables across project phases. This is typical for projects conducted in a waterfall fashion and for schedule-oriented projects.
  • Spreading deliverables across knowledge areas. Project teams  organized by areas of expertise (such as operations, legal or  finance) usually use this technique in their projects.  
  • Spreading deliverable across processes. This is typical for process-oriented projects.
  • Spreading deliverables across sub-projects. This is most effective in big projects with added complexity, where deliverables are specific for parts of the project but not for the project as a whole. 
  • Organizing deliverables hierarchically, from major deliverables to sub-deliverables. This is best for product-oriented projects.
As a side note, in agile projects, where teams are action-oriented, the work decomposition is done slightly different. The focus then is on epics, user stories and on the functionality to be delivered.

To decompose requirements effectively, I recommend following these tips:

  1. Break down the work in deliverables and sub-deliverables by focusing on "what" to deliver. Remember that decomposing requirements happens during the early stages of the project. Don't ask "when" in the project phase it will be delivered or "who" is going to take care of it. Save these questions for later, when sequencing the project work and building the project schedule.
  2. Organize the deliverables based on their relation to each other. Use a graphical form, such as a hierarchical tree (i.e., work breakdown structure, or WBS), a relationship diagram or a mind map diagram.
  3. Avoid over-decomposition — that is, excessively breaking down or over-detailing work. This leads to micromanagement or inefficient work management. A good general rule is to decompose requirements to the point where you can estimate deliverables, costs and time, and verify and measure results. 
  4. Since you are dealing with deliverables and not activities, use nouns to describe each deliverable. Don't use verbs, adverbs or other action-driven labels.
  5. Verify the accuracy of the decomposition at the end of each level. Each sub-deliverable should add up to 100 percent of the deliverable above it. 
Focusing mainly and steadily on the "what" is a pragmatic and efficient planning approach as you set up the project.

How do you decompose requirements?

Learn about the basics of project work planning, including the four main steps of planning.

The Scoop on Requirements Scoping

| | Comments (1)
We've all been there. When a project's scope isn't properly managed, it can lead to schedule delays, budget overruns or not meeting project goals.

Requirements scoping can help keep projects under control by establishing what criteria — such as prioritization — will drive decisions. The process also clearly details what the project will deliver, and perhaps just as importantly, what it won't.

Depending on a project's complexity, goals and project management approaches, there are various ways to manage requirements scoping. Here are three of the most common.

1. Early scoping assumes all scoping is done as part of the project charter or during the scope definition. The approach relies on precise estimations of required resources, budget and time. It discourages scope creep and requirements changes.

The advantage of early scoping is that it facilitates starting project work ahead of time. On the other hand, poorly estimated efforts can translate into budget or schedule overruns, resources bottlenecks or missed project goals. 

Early scoping is recommended for projects where the main focus is on the scope, and on ones with no, or minimal, budget and schedule constraints. For example, early scoping works well on consolidation or integration projects, where the constraints on the scope (budget limitations, for instance) impact objectives.

2. Late scoping is performed after collecting, analyzing and even designing the requirements. At such late stages, efforts estimates are much easier to assess and generally more accurate.

Although late scoping can keep a project within budget and schedule boundaries, this approach has a considerable downside: Efforts spent for out-of-scope requirements are wasted or deferred. Consequently, this leaves less time, budget and resources for addressing in-scope requirements — the ones that matter.

Late scoping is recommended for projects addressing requirements that have similar (and not critical) relevance for the project's outcome — for example, regular maintenance projects.

3. Iterative scoping is a balanced, incremental approach. The entire scope is broken down and prioritized by items that have the highest relevance. These will be addressed in the first scoping round. The rest of the requirements, as well as potential changes or rework, are subject to scoping in subsequent iterations. 

The requirements scoping and the project work advance in a rolling wave approach. Iterative scoping is especially useful for IT and agile projects.

How do you manage requirements scoping on your projects?

Gather More Than Just Requirements

| | Comments (1)
When managing requirements, we naturally focus primarily on the business need or opportunity the requirements will address. We pay attention to how requirements are formulated, and whether they are clear, comprehensive and aligned to the project goals.

There's nothing wrong with focusing on the "what" of requirements — that is, what is asked to be delivered. But to avoid any major problems during the project, it's also important to identify the related assumptions, constraints, dependencies and risks. 

A requirement assumption is a condition or event that's assumed to be true or false, or that is supposed to happen or not, that directly influences the requirement's context. On the other hand, a requirement constraint is an imposed limitation to the requirement's context.

A requirement dependency is a direct correlation between two or more requirements, where the result of one requirement influences the outcome of others. And a requirement risk is the uncertainty of a requirement. 

For example, consider a project to develop a shopping website. One of the business requirements is to allow customers to perform credit card payments for their purchases. 

This particular requirement assumption presumes that customers will both own a credit card and be willing to pay with it online. 

If we would limit credit card payments to U.S. customers only, we would be dealing with a requirement constraint

The requirement would have an additional assumption and at the same time a requirement dependency on another requirement — that the website must be capable of handling credit card transactions. 

On the other hand, one of the requirement risks would be the security of payment transactions.

While this may seem like too many factors to keep track of, gathering these related elements doesn't have to be difficult. Personally, I document requirement assumptions, constraints and dependencies in a dedicated log, and include them as part of the project scope statement. I also use them while sequencing activities on the project schedule, and for assigning activities leads and lags.

Concerning risks, I consider project scope and project requirements as two of the main sources for identifying risks on a project. Interestingly, another risk will be the assumptions, constraints and dependencies themselves, because they can also create a negative or positive possibility of risks.

Regardless of the risk source, I recommend tracking requirements risks in the risk register and addressing them during the scope-definition stage and as part of the risk management process throughout the project.

How do you manage requirements assumptions, constraints, dependencies and risks on your projects?

Guidelines to Plan and Facilitate a Brainstorming Session

| | Comments (6)
In a previous post, I referred to brainstorming as one of the most constructive and fruitful techniques to collect project requirements.

Brainstorming can be similarly effective and efficient when applied to solving challenges in a project. Project managers can gather the project team together and brainstorm for creative ways to address the issues.

In a brainstorming session, the project manager can take on the planner role, as well as the facilitator role.

As a planner, project managers might consider the following guidelines:

  1. Clearly outline the problem or the idea to be explored.
  2. Define basic ground rules, such as no criticizing, analyzing or judging ideas during the session. Criticism inhibits creativity. The ideas evaluation should be done at the end of the session.
  3. Depending on the complexity of the targeted problem or idea, plan the session with no more than five to 10 people. In a larger group, it's challenging for everyone to participate.
  4. When looking to develop new ideas or concepts, gather a mixed audience to gain a wider perspective. On the other hand, if looking to solve a problem, gather people from a focused or specialized group.
  5. Schedule sufficient time so that people won't feel constrained. Factor in time for breaks so that people can feel refreshed.
  6. Have someone capturing the generated ideas and the underlying notes. 
  7. Plan the logistics such as use of flip charts, pin boards, snacks, etc.
As a facilitator, project managers might consider the following best practices:

  1. Create a relaxed atmosphere that stimulates creativity.
  2. Start the session with an icebreaker, a warm-up exercise or something funny.
  3. Allow open brainstorming but keep the focus on the initial idea or problem.
  4. Encourage everyone to participate and ensure a fair participation from each attendee.
  5. Accept all ideas positively and appraise them equally.
  6. Encourage people to be constructive, as well as to build on people's ideas.
  7. Keep the session unstructured and unconstrained.
Do you use brainstorming on your projects? What is your experience and results?

Create a Project Plan to Reach Success

| | Comments (1)
In project management, if basic technical knowledge is lacking, or the basics are ignored or underestimated, a project's success is not guaranteed.

On the contrary, mastering the project management basics is a prerequisite for project success.

PMI's 2012 Pulse of the Profession revealed that organizations that use basic, standardized project management practices have a 71 percent success rate, compared to the average success rate of 64 percent.

One of these basic pillar practices is taking the time to create a realistic implementation plan. But how do we build a comprehensive, yet realistic project implementation plan? Here are a few tips:

1. Start the project plan while keeping the final objective in focus. Write down and highlight why the project is being conducted and what the project objectives are.

2. Make sure that the project's requirements and overall project scope are clearly captured, along with the project deliverables and the given constraints.
3. Implement a well-defined change management process, agreed upon by all stakeholders. The Pulse report revealed that of the projects that used change management, 71 percent were successful.

4. Document the estimated project costs, the funding approach, how the actual costs will be monitored and how cost deviations will be handled.

5. Plan how project communication will be managed. Who are the project stakeholders? What are their project roles and responsibilities and how can they influence the project?

6. Do not underestimate the risks the project can encounter. The Pulse also showed that 72 percent of successful projects used risk management. Assess and document risks throughout the project and plan for mitigation and contingency approaches.
What role does project management basics and the project plan play on your projects?

To discuss Pulse of the Profession on Twitter, please use #pmipulse.

See more on the Pulse of the Profession.

Plan for Special Events on Your Project Calendar

| | Comments (0)
The months of July and August have a few events that can put kinks in your project plans in the Gulf Cooperation Council (GCC) countries.

During the summer, for example, temperatures can reach as high as 122 degrees Fahrenheit (50 degrees Celsius).

Project managers working with or in the Muslim world also need to plan for Ramadan, when the majority of the population fasts between sunrise and sunset. Then there's Eid al-Fitr, a national holiday that marks the end of Ramadan. Its importance is similar in scale to Christmas or Yom Kippur.

These combined events mean project managers must plan meticulously to ensure minimum disruption to their project schedules.
During this one month, the expected impact on the construction sector alone is a reduction of productivity by 40 to 60 percent. The main causes are heat and a fasting workforce that is unable to work at full capacity.

Additionally, project managers in construction face government constraints, which forbid laborers to work more than six-hour shifts in the day. They must stop working at noon and wait until it gets cooler to start again.

To keep project schedules moving during the very hot weather and major holiday, the key is to plan, plan -- and plan some more. These planning best practices can help:

  1. Begin planning for special events about three months prior. The project manger should meet with the customer, contractors and suppliers to agree on expectations, tasks and deadlines.
  2. Determine activities that can be moved up or delayed to compensate for risks during the special event, such as climate, absent staff and lower productivity.
  3.  Employ more staff to compensate for loss of productivity. 
  4. Keep a sharp eye on daily logs. Doing so will minimize risk -- especially in cases where work hours or the calendar have been altered and extra resources have been employed.
  5. Communicate with teams on when they expect to complete tasks. Coordinate dates and lines of escalation in the absence of managers.
  6. Ensure health and safety of employees in the work place. In the case of heat, plan for generators to cool work sites, for example. Provide plenty of water, appropriate clothing and equipment.
How do you plan for special events in your project calendar?

Group Creativity Techniques to Collect Requirements

| | Comments (2)
In my previous post, I discussed gathering requirements through a facilitated requirements workshop, conducted as part of the scoping phase.

A few creative group techniques allow a project manager to get the most out of a requirements workshop. They include mind mapping, brainstorming, affinity diagram, nominal group technique and Delphi technique. (A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Chapter 5.1.)

The rigor, the number of applied techniques and the sequence in which these techniques are applied depend on the project's complexity, the workshop audience and the available time for gathering and prioritizing requirements.

Nevertheless, the following approach can be constructive and fruitful for collecting project requirements in a facilitated workshop:

1. Start gathering requirements by using the mind mapping technique.
Start with a topic, an issue or an area that you want to collect requirements for and develop ideas around it. Group the ideas visually, as a mind map, by writing down each idea and drawing how it relates to the initial topic. Ideally, you let anyone in the workshop create his or her own mind map.

2. Continue the process with a brainstorming session.
Allow anyone in the workshop to generate an unstructured requirements list for each idea captured on the mind map. To ensure that the brainstorming remains focused on the initial topic, lay basic ground rules and let anyone freely generate fresh ideas and requirements on the topic.

3. Use the list of unstructured ideas and requirements to build an affinity diagram, where your ideas are organized into groups based on their natural relationship. Let anyone in the workshop participate in organizing the items in the most natural group they can.

4. Identify the most important requirements by applying the nominal group technique. Allow each member or group in the workshop to identify which requirements are the most important for him or her. Rank each requirement on the affinity diagram with a priority: low, medium, high or from one to five. To avoid conflicts, facilitate an anonymous priority appraisal and ranking. Finally, tally the results and identify the most important requirements.

5. Close the process by running several rounds of independent feedback through the Delphi technique. Let any individual or group revise the list of requirements. Share an anonymous outcome from each review round and continue with further rounds, keeping in mind the objective to reach consensus and convergence.

Which of the group techniques are you using for collecting requirements? How do you apply them on your projects?

PMI Members: Learn more about mind mapping in our Knowledge Center.

Plan and Facilitate a Requirements Workshop

| | Comments (2)
Every project manager knows that there is no single best way to collect project requirements. 

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Fourth Edition identifies several tools and approaches for collecting requirements. They include interviews and focus groups, facilitated workshops, group creativity and group decision-making techniques. 

Combining some of these tools and techniques with a requirements workshop can be the most efficient and effective requirements elicitation approach. But only if the workshop is planned and facilitated well.

Planning a requirements workshop is no different than planning any meeting or event. Some simple steps to follow:
1. Define the scope and establish an agenda 
The scope and agenda should make it clear to all participants the reasons why they are attending the workshop. 

2. Invite the right people 
Generally, you want to keep the guest list short, but make sure to invite key stakeholders. These include representatives from teams or user groups that will benefit from the project's outcome, project sponsors, product or system owners, and business and technical consultants. 

3. Plan the logistics 
To facilitate an open and constructive working session, make sure that the workshop's location and environment has sufficient capacity and appropriate equipment for hosting the workshop. 

Now that we have a good plan, how do we facilitate the workshop? 

1. Lay ground rules 
Establish basic ground rules. For example, start on time, stay in scope, and respect and build on other people's ideas. 

2. Gather requirements 
Get everyone involved through questioning and individual interviewing. Apply group creativity techniques, such as brainstorming and mind mapping. And for topics that require in-depth and focused discussions, organize dedicated breakout sessions. 

3. Record the workshop 
Make sure that someone attends the workshop solely to write the protocol during the workshop. He or she should capture all requirements, ideas, assumptions, risks and open items. 

4. Pre-qualify and pre-prioritize requirements 
To facilitate the scoping process at a later stage, try to leave a requirements workshop with pre-qualified and pre-prioritized requirements. 

5. Review the protocol and develop a follow-up plan 
At the end of the workshop, plan sufficient time to review the written protocol and the derived action items. Develop a follow-up plan to address the open items. Identify the owner of each item, and establish deadlines and next-steps. 

Do you hold requirements workshops? If so, how do you plan and facilitate them?

A Project With No Project Charter?

| | Comments (3)
Also known as the project initiation document, the project charter is a high-level document created at the start of a project and referred to throughout the project's duration. It is the foundation of the project, a basis for how the project can evolve. The charter should state the purpose, main objectives and vision for a project.

Many project professionals may consider the project charter as 'more documentation' or a 'mere formality.' But the truth is that if they start to consider creating a charter as a best practice, many problems or issues can be eliminated.

However, I regularly meet project managers that manage their projects without referring to or even knowing the existence of their project's charter.


Here are some reasons a charter is left out, based on my experience:

  1. Project management immaturity, lack of project approaches or poor project governance by the sponsor or organization. There's a lack of awareness for the need of a charter or formal authorization process.
  2. At project initiation, there are no clear measurable objectives or reasons for the project. Hence, there is nothing to write.
  3. The charter may have been written, but is filed away or lost within the organization's documentation system. This could be a symptom of high staff turnover or poor information systems.
  4. Requirements and other changes to the project deemed the existing project charter obsolete.
  5. The project has been initiated or is continuing without real executive commitment. 
  6. The project is considered too small or simple to be chartered, so writing a charter is considered a 'waste of time.' 
  7. A charter may exist but contains information that is rigid. Details, budgets and milestones may be unrealistic and unachievable, and therefore not referred to.
  8. Alternatively, the metrics and information contained in the charter may be too broad and ambiguous and therefore not referred to.
However, without a charter, a project is headed for problems including:

Risk of diminished value and importance of a project, if its purpose and strategic benefit are not documented, agreed and formally recognized.

Delayed decision-making. Getting management and sponsors to sign off on things becomes difficult. There is no one to champion for the project and responsibility for it is passed around.

Difficulty managing expectations. Without a collectively agreed to charter, there may be frequent disruptions and disagreements from stakeholders. They will have differing intentions, opinions and understanding of the project's outcomes.

Risk of failure. When there is no clear, recorded statement of a project's goals, it's more prone to fail. The project charter includes the business case and other additions, which serves as a constant reminder of the project's vision, mission and critical success factors.

Lack of authority. The project manager will be plagued with problems from lack of authority to spend the budget, the ability to acquire and assign resources, and a general power needed to make day-to-day decisions and actions. This will also make it harder for the project manager to attract good suppliers, vendors and resources to work on the project. This can create a culture of dissatisfaction and apathy within the existing project team.

Subject to scrutiny, delay and bureaucracy. The project can expect numerous changes and deviations, which increase the risk of not delivering and reaching the projects goal. It could eventually become a financial burden to the organization.

Do you know of any other reasons why a project charter would not be created? How can the lack of a charter plague a project?

Use Military Ideas to Get Buy-in From Your Project Team

| | Comments (3)
Carl Phillip Gottfried von Clausewitz, (1780-1831) a Prussian soldier and German military theorist, wrote:

"War is the realm of uncertainty; three quarters of the factors on which action in war is based are wrapped in a fog of greater or lesser uncertainty ... The commander must work in a medium which his eyes cannot see; which his best deductive powers cannot always fathom; and with which, because of constant changes, he can rarely become familiar."  

Projects aren't much different.

Military leaders and project managers both need the active support of their teams to be successful. But support involves more than just following orders. Active supporters work with you to achieve success in difficult circumstances.

Here are a few theories I've adapted from the military that may help project managers running a large project:

The right of one objection
This doctrine says that regardless of the rank of the person giving the command, if you have information that shows the command may be wrong, you are obliged to share that information with the issuer. Once the objection has been properly considered, the objector is expected to comply with the final decision.

Unfortunately, many project team members tend to keep information to themselves rather than risk getting in trouble with authority. To reduce the concern, adopt a policy guaranteeing no sanctions against a team member who raises the one objection. More importantly, information withholders become liable to an equal share of the consequences if they have kept quiet.

Decentralize execution planning to the lowest possible management level. This way, those who must execute the work have the freedom to develop their own plans.
At each level of management, the plan should dictate a subordinate's actions only to the minimum degree necessary. Ideally, rather than dictating a subordinate's actions, a good project plan should create opportunities for the subordinate to act with initiative.

Effective planning should facilitate shaping the conditions of the situation to our advantage while preserving freedom to adapt quickly to changes in the project's circumstances.

Planning should be participatory and evolutionary. The main benefit of planning is engaging in the process -- the planning matters more than the plan.

We should view any project plan as merely a common starting point from which to adapt as required -- and not as a script that must be followed. Plan far enough into the future to maintain the initiative and prepare adequately for upcoming phases, but not so far that plans will have little in common with actual developments.

Adapt these ideas to the circumstances of your project, and they should help you make your internal stakeholder management more effective and your projects more successful.

Craft "High-Quality" Requirements

| | Comments (4) | TrackBacks (0)
Project requirements derive from concrete business needs or business-use cases and constitute the foundation for the project work. Without requirements, projects cannot exist.

Incomplete and unclear requirements may result in project failure. Moreover a significant part of project rework is attributable to problems with the project requirements.

On the other hand, requirements that are clear, complete and understood by all the parties are of "high quality." They build a solid foundation for the project work.

Collecting high quality requirements can be a challenging endeavor for several reasons:

•    Stakeholders often don't speak the same language (business vs. technical)

•    Stakeholders have different understandings and views of the product

•    Stakeholders have different backgrounds and expertise on the matter

It may not be the project manager's role to collect, qualify and write requirements. But he or she is often the one planning the framework and determining or approving the guidelines by which requirements are elicited, qualified and accepted.

The following guidelines should help in collecting high-quality project requirements:

1. No requirements without a use case
Usually, requirements can be linked to concrete business cases, which are generally task- and user-centric. Use cases help understanding the requirements' context and purpose.

2. Requirements language
Pay attention to the wording. Avoid ambiguous words. Use words and terms consistently.

You might consider using a glossary of terms to ensure common understanding.

Avoid words that have subjective meaning (nice, substantial, safe, simple) and that enforce direction weakly or that undermine commitment (often, always, partially, usually). Use "shall" or "must" instead of "should" or "might."

Remove any room for interpretation. Avoid the usage of "and/or" together or "including but not limited to."

3. Requirements characteristics checklist
Build a checklist of requirements characteristics that are relevant to your project's quality standards. Evaluate each requirement against the checklist.

Here are 10 characteristics that I successfully use to evaluate the quality of requirements:

Atomic: Is this a single requirement or multiple requirements in one?

Complete: Is this comprehensive enough to start working on it?

Traceable: Is this related to a use-case or need?

Logical and Clear: Does it make sense? Does it leave no room for interpretation?

Consistent: Is this consistent with the project objectives and other related requirements?

Measurable: Is this measurable once a solution is delivered?

Compliant: Is this aligned to the current product features, system architecture and legal framework?

Feasible: Is this realistic and doable given the complexity and the project context and constraints?

Necessary: Is this really required given the project objectives and constraints?  Or is it more of a want than a need?

Prioritized: What are its criticality, urgency and priority?

What best practices do you use to ensure that project requirements are of high quality?

Use a Framework to Plan Project Requirements

| | Comments (3)
Project requirements are rarely collected and made available in a final form to a project team. Instead, requirements are often collected through an elicitation process, which involves a discovery, analysis, understanding and validation endeavor.

Usually, a business or requirements analyst carries out the requirements elicitation process. The project manager is typically responsible for planning and setting up the requirements elicitation and management framework.

Well-planned and well-managed project requirements are common characteristics of successful projects.

This simplified framework can be a guiding requirements checklist for project managers:

Organizational assets: Identify the available organizational process assets for planning and managing project requirements. The organization or project management office might already have standards, guidelines and templates that can or should be used as a starting point.

Stakeholders: Use the stakeholder register to identify the stakeholders who will help provide, collect, analyze and document the project requirements.  

Categories: Identify and categorize the requirements types that are to be elicited, such as:
  • Project requirements: Business requirements, end-user requirements, functional and non-functional requirements, etc.
  • Product requirements: Technical requirements, product features, functional requirements, etc. 
  • Indirect requirements: Overhead imposed by organizational or enterprise environment and standards related to security, regulations, infrastructure and industry, etc.
Channels: Identify the channels through which requirements will come in, such as business-use cases, focus groups, requirements workshops, surveys, product introspection, reverse engineering or  imposed by the organization.

Documentation: Identify how requirements will be documented, whether it's textual form, graphically or using a formal requirements language. Identify the way requirements will be tracked -- through requirement tools, Word documents or spreadsheets.  

Maturity Index: Establish the criteria by which requirements are validated and qualified. Is it clear? Does it make sense? Is the criteria aligned to the project vision and goals?  

Prioritization: Identify the criteria on how requirements will be prioritized and scoped. For instance, list the must-haves first. Then come the "quick wins," requirements based on the owner prioritization, complexity and costs, the project phase, etc.

Risks: One of the main inputs for the project risk management plan are the scoped requirements. Identify the requirements posing a risk to the project. Develop risk mitigation, response and tracking plans.

Change management: Establish the criteria for detecting scope creep and basic rules for handling requirements changes for applying the change management process.  

How are you planning and managing your project requirements?

See more posts from Marian.

See more on project planning.

Plan an Effective Project Meeting

| | Comments (5)
On a project management forum I frequent, someone asked whether or not it was rude to use digital devices during meetings.

Some responses were flat out rejections of using digital devices. Other responses were accepting of using technology while others are speaking.   

Personally, if you are not being disruptive, I don't think it's rude to use your digital devices in a meeting. I think what's more important to note is why people are using their digital devices during the meeting.

As a new project manager, you will probably be hosting many meetings for a project.  It's up to you to stay focused even if the participants aren't captivated the entire time.

As project managers in general, we should really take a good look at why we call meetings at all.

You may think you've called everyone together to get their input. But how many people did you invite? What often happens is that a few  people talk at once, and several people are left out and unable to contribute.They will inevitably find a more useful way to spend their time.  

You may think you've called a meeting at a good time because everyone was available on the calendar at the same time -- finally. But realistically, almost everyone has something going on before and after your meeting. Your meeting isn't the only thing occupying their attention. An empty space on a calendar really isn't an empty space.

As project managers, we need to ask ourselves what kind of meetings we are calling, what's the purpose, who must be invited and why to determine if a meeting is the absolute best way for you to impart or gather a particular type of information. The reason for calling a meeting should not be because it's the easiest way to give information or to get input.   

If you do find that you must meet, consider having several smaller meetings in small spaces that engage your core audience. Invite three to five people instead of a huge group. You can even adopt the agile practice of having 15-minute stand-up meetings to encourage groups to focus and get through agenda items quickly.  

Sitting in a room waiting to be engaged is bound to lose anyone's attention. If you keep your attendee list short, even if the meeting is long, there is more audience engagement and less individual downtime. Most importantly, there is less opportunity for someone to tune out because they feel no one is paying attention to them.

How do you engage team members during meetings, and do you care if they use digital devices?    

Read more posts from Taralyn.

Read more about project planning.

Building Blocks of Project Work Planning

| | Comments (3) | TrackBacks (0)

In my previous posts, I laid out the basics, the framework and the key documents for planning a project end-to-end. Now it's time to dive deeper.

One of the most essential project planning stages is to establish the grounds for the project work. Planning and defining the project work starts with defining the "what" of the project.

Before you can begin, you must understand the business needs and identify the project deliverables and its characteristics. You must set the boundaries of the project by establishing what the project will and will not deliver, and break down the project work into smaller and more manageable work units.

The building blocks of project work planning have four main steps:

  1. Collect the project requirements
  2. Facilitate a requirements workshop
  3. Define the project scope
  4. Break down the work in small work units
Collecting requirements is the process of understanding the customer needs, the business use-cases or the required product features and functionality that the project will deliver. It's an elicitation process, a discovery and analysis endeavor, rather than just a gathering effort.

The requirements elicitation process should be facilitated and not done by yourself. Therefore, do this. Get the appropriate project stakeholders together. Organize focused requirements workshops. Interview, brainstorm and job shadow to glean information.

Defining the project scope involves prioritizing the collected requirements, and deciding what's in and out of scope based on such factors as criticality, priority, urgency, constraints, complexity, risks and costs.

The scope covers the project deliverables and all project requirements, along with their detailed descriptions and the related constraints and assumptions. The scope illustrates the entire work that the project will carry out, as well as the project boundaries.

The part of the work planning that generates action is the Work Breakdown Structure (WBS). The WBS enhances the project scope understanding by decomposing the project work and deliverables into smaller and more manageable work units, also called work packages. The WBS defines granularly the "whats" of the project.

Do you agree with these steps? How many steps do you use for project work planning?

Read more posts from Marian Haus.

Project Management Plan: The Basics

| | Comments (2) | TrackBacks (0)
In a previous post, 7 Essential Project Planning Documents, I referred to the "Project Management Plan" as one of the key planning documents that fosters project success. 

Sometimes people confuse the project management plan with the schedule or the scope plan. But it's more than that. 

A project management plan is the planning document, capturing the entire project end-to-end, covering all project phases, from initiation through planning, execution and closure. 

A comprehensive plan covers at least the followings areas and components: 
(Note: A Guide to the Project Management Body of Knowledge (PMBOK® Guide -- Fourth Edition) covers these in Chapter 3. Instead of putting the elements one by one, I grouped them by purpose/meaning.)

  • Overview: Why the project is being conducted and its primary objectives 
  • Scope: Business needs, requirements, deliverables, constraints and work breakdown structure 
  • Schedule: Activities schedule and project milestones 
  • Costs: Project budget and its funding approach
  • Quality: Quality measurement and control approach
  • Project team: The people working on the project, their roles and responsibilities 
  • Communication: Communication type, channels and the reporting approach 
  • Risks: Risk index, methods to identify and evaluate risks, risk mitigation and contingency planning
  • Procurements: Required procurements and purchase processes
  • Closure: Closure approach, including the deliverables hand-off protocol 
  • Changes: Procedures used to track changes in the project 
  • Baselines: Scope, schedule and budget baselines
When writing a project management plan, the approach depends again
on the project's size and context. I personally use the following approaches:

  • The master document approach is where the entire project, with all the underlying planning details, is documented within the same master plan.
  • The index approach, when all subsidiary planning documents are written as separated documents and linked or referenced in an index-like plan.
What approach do you use when crafting a project management plan? What elements do you use?

"Requirements" for Managing Your Project and Team

| | Comments (2) | TrackBacks (0)

Editor's note: The title of this post was changed on 9 December 2011.

Do you make time to identify your requirements for managing a project? Sure, you plan and manage the project, but as a program or project manager do you also identify your needs for running the project and the team?

It's important to know what we require of our team and stakeholders. When these needs are clearly identified and communicated, it's easier to track and manage the related project tasks and variables.

For example, I recommend that you require your stakeholders to attend meetings and give input during the change management process. You'll need the decision makers to assist you in evaluating the need for change.

When you set and express this participation as a requirement, your stakeholders understand your requirements and their own importance. Further, when a change is requested during the project, it doesn't come as a surprise that you expect stakeholders to be involved in the process.

When it comes to your project team, maybe you require team members to be on time for meetings and to submit progress updates. Communicating this as a need and setting the expectation helps ensure that team members give timely feedback when needed. When team members meet this particular need, you're able to meet your own deadlines with the customer.

Setting and communicating project management requirements are nothing new. For the most part, these needs are automatically expected from everyone involved in the project. But failure to pen down and communicate each need usually leads to more project challenges. For example, team members may start to argue, finger-point or shake off their responsibilities. There's also the possibility of missing a milestone -- and that's something to avoid.

Take time as the project manager to set your requirements for running the project. And do so as a high priority.

What requirements do you establish for managing a project? Do you communicate these to the project team and stakeholders?

Disciplined Project Management

| | Comments (6) | TrackBacks (0)
We can all boast of great methods of managing people and project deliverables. But what gets the job done is discipline.

And it's interesting to note how the team follows the leader: The more disciplined the leader, the more disciplined the team. A disciplined leader gives others an anchor -- a sense of stability and accountability.

You may wonder why some people are disciplined and others are not. I believe it's a choice. Disciplined project managers strongly believe that delivering on the project result is a function of project management science and disciplined execution.

Here are some ways to become a disciplined project manager:

-    Plan the next work week's activities a day or two ahead of time
-    Confirm activities the day before
-    Conduct daily reviews of what you did or didn't accomplish
-    Follow through on your commitments
-    Avoid time-wasters, such as unrelated conversations
-    Practice staying within the time allotted to the meetings, tasks and activities
-    Hold yourself accountable for your own deliverables by using a daily tracker document
-    Communicate with stakeholders and sponsors regularly, regardless of the results

What are the ways you've become a disciplined project manager? And how has it helped you deliver better results?

See more posts from Dmitri.

7 Essential Project Planning Documents

| | Comments (10) | TrackBacks (0)
Solid project planning is a prerequisite for project success. Poor planning, meanwhile, can lead to missed deadlines, budget overruns, poor quality deliverables, frustrated project teams and even project failure.

In my previous post, I offered five steps to assist in planning the project-planning phase. One of those steps involved preparing planning documents.

To foster a successful planning phase, here are seven planning documents I believe most project managers will find indispensable. This list certainly might vary depending on the project setup, project size, complexity and organizational planning guidelines.

1. Project management plan -- This is used as a reference index, encompassing all planning and project documents.

2. High-level project schedule plan -- This document captures high-level project phases and key milestones. It is the document most project stakeholders will see or want to see.

3. Project team planning -- This document provides a "who-is-doing-what" view of the project. This document fosters efficient project execution and effective project communication.

4. Scope plan -- The scope plan documents the project requirements, the agreed scope and the Requirements Traceability Matrix (RTM) summary.

5. Detailed project work plan -- This keeps track of the activities, work packages, resources, durations, costs, milestones, project's critical path, etc. It will be an essential document and work guideline for your core project team.

6. Quality assurance planning -- This document tracks the quality standards your project deliverables will have to align to. These may typically include product testing approach and tools, quality policies, quality checklists, deviations definitions, quality metrics, product defect severity grades, acceptance criteria, cost of poor quality, etc.

7. Risk planning -- This document contains the project risks and the related mitigation plans; as well as the project opportunities and the related exploiting plans. The importance of this document is one of the most underestimated in project planning. Be prepared to have a contingency plan in case something goes wrong or to take advantage of opportunities when they arise.

Start with this checklist when you sit down to plan for your next project-planning phase. Depending on your project's needs, fine tune the checklist and tailor it by adding and removing planning assets, determining the planning time frame, the underlying details and rigor.

Revisit this planning exercise, learn from it and enhance it, to continuously improve your project planning skills.

What project planning documents do you find indispensable?

See other posts from Marian.

5 Steps to Plan the Project Planning

| | Comments (6) | TrackBacks (0)
There is a saying: "Every minute you spend planning will save you 10 minutes in execution." As a project manager, I've learned that along with communication and execution, planning is one of the three key ingredients for project success.

Planning is not just a one-off activity completed in the early stages of a project. Planning is a process (or rather a group of processes), conducted throughout the project. And like every process, planning itself requires a plan and a setup, which defines the planning scope, details and deliverables.

So how do we plan the planning? Here is my five-step approach:

1. Decide on the project management methodology, framework or practice you will use on the project. Depending on the approach, you might require different planning styles, deliverables, details or rigor.

You might have to go ahead with a detailed planning process if you will use a waterfall approach. Conversely, you might have to keep the planning thin if you will use an agile approach, such as scrum. Or, your planning might be predefined and framed if you have to use your organization's proprietary methodology.

2. Plan project time for planning. In average, at least 10 percent of management time should be allocated to project planning.

3. Write down a checklist of all project documents you plan or need to deliver. The list will mostly depend on your project's complexity, organization and methodology. (More on this in my next post.)

4. Start planning early and continue planning throughout the project.
Some of the planning documents, such as the high-level schedule or scoping documents, might have to be kept frozen upon sign-off. Other documents, such as the risk management planning or rollout planning, will typically require updating as the project progresses.

5. Continuously improve your planning.
Improve planning by communicating the planning outcome with your project team and by collecting their feedback regarding your planning performance. You can use this feedback for continuous planning improvement.

As the project progresses, keep a log of your planning issues to track gaps you encounter along the way. This is the "planning lessons-learned" document that you can also use for continuous improvement.

What do you think? How do you plan for project planning?

See more on project planning.

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll