Agile Project Management Methodology

What is Agile Project Management Methodology?

There is lots of talk about an emerging approach to project management called “Agile Project Management Methodology.”  Agile Project ManagementUnderstandably, some may confuse this with managing an AGILE software development effort as part of an organization’s  SDLC (Systems Development LifeCycle). All caps will be used to identify the software development methodology).  Recently,  PMI (Project Management Institute) began offering a “PMI-ACP Certification” (Agile Certified Practitioner). Project Methodology Main Page.

I talked with several practicing senior-level technology, business, and various industry project managers regarding their understanding of “Agile Project Management Methodology.”  Each of these experienced managers had a different interpretation of what this might mean but none had actually implemented this specific approach within their firms.  However, one organization was in the early stage of adopting an Agile Methodology Playbook.

The consensus was that Agile Project Management Methodology grew from the desire to produce results (deliverables) faster and reduce bureaucracy and burdensome “administrivia.”  The respondents also believed that if a project was primarily a business process reengineering effort (i.e., how do we eliminate duplicate work efforts within an operations team?), it probably would not be using Agile Project Management Methodology.  Time will tell if this proves to be correct.

A quick overview of AGILE software development is in order here. It is an iterative application development effort where requirements and solutions evolve through collaboration among developers, business owners, stakeholders, project sponsors, and end users (clients).  This methodology was developed almost fifteen years ago as an alternative to the heavyweight, document-driven software development processes such as waterfall (application development progress flows from one stage to another, incorporating feedback).  Within AGILE, a well-known software methodology is Scrum. It identifies “sprints” to produce smaller deliverables (deliver software “early and often”).  Changing requirements are expected and there is close, daily cooperation and communication between business people and developers.  Team members are co-located team members when it’s possible.

Most organizations have their own specific project methodology and if AGILE is part of their SDLC, it most likely has been customized to meet the needs of that organization.

While AGILE has been successful in many instances, it presents challenges for very large implementations and in large organizations where a centralized IT team supports multiple business enterprises.  Technology teams typically have a good understanding of what AGILE means. But business users, project sponsors, and stakeholders may not be as clear.  So detailed planning and excellent communication are key to ensure agreement as to exactly what functionality will be delivered “early and often”, as well as the quality of that deliverable (i.e., what bugs will be fixed when, and how will they be retested?)

Additional challenges arise when an AGILE development approach, which may fall under Agile Project Management Methodology, is supported at the corporate level. This is particularly true when you’re implementing a new vendor-based software solution. Individual enterprises may need to continue following a waterfall development approach when they have older legacy systems with multiple integration points. This situation creates frustrations, conflicts, and costly regression testing.

Any methodology should be viewed as the framework within which a project manager executes solid project management skills. They tailor the methodology to the specific organization and actively manage process interactions (i.e., scope change will affect cost and require trade-offs).  Managing in an “agile” way has always been a core competency of successful project managers.  Adopting an Agile Project Management Methodology should not be interpreted as a way to do an end-run around controls. Nor is it a license to take short-cuts through the critical processes of project management, (initiating, planning, executing, monitoring and controlling).  Instead, it should be viewed as an opportunity to consider a new and, hopefully, improved way of achieving success.

It is still not entirely clear if managing an AGILE software development effort automatically qualifies as adopting an “Agile Project Management Methodology” approach. Perhaps there is now a broader meaning to this project management approach which may or may not involve AGILE software development. It may just infer producing results faster.   Hopefully this will be made clearer over time. It will be interesting to track this Agile Project Management Methodology and to note how it is improving overall project management execution and delivery. It must be evaluated from the perspective of the project team, project sponsors, stakeholders, and end users.

Agile Project Management Lessons Learned

At the beginning of your 4pm course, when you and Dick talk to design your program and what you want to learn, you will select case studies that fit the kind of projects you want to manage. Chose you course and then select the which specialty case study from business, or marketing,  or construction, or healthcare, or consulting.  That way your case studies and project plans, schedules and presentations will fit your desired specialty.

  1. 101 Project Management Basics
  2. 103 Advanced Project Management Tools
  3. 201 Managing Programs, Portfolios & Multiple Projects
  4. 203 Presentation and Negotiation Skills
  5. 304 Strategy & Tactics in Project management

Failed Projects

Dick Billows, PMP
Dick Billows, PMP
Dick’s Books on Amazon

“This project has to succeed; it’s critical to our organization. We can’t have a failed project!” You have probably heard this a hundred times during your career. Yet many organizations have lots of failed projects. Sometimes they’re as high as 70%.  The failure rate for projects sponsored by certain executives are even higher because they have no idea how to sponsor a project. Sometimes failed projects are delivering so little value to the organization that the executives stop work on them. But that’s pretty rare because often there is too much political and financial capital invested to admit failure.  So the failed project continues even when it is so out of control that no one can find a way to salvage it.

Most organizations don’t learn from their project failures so they have one failed project after another. In those organizations, 70% of the projects fail to deliver the scope for anywhere near the planned cost. Every project failure should lead to a detailed investigation of what went wrong. Organization must circulate that information to executives and project managers. Unfortunately, very often the failures are hidden and there is no investigation into what went wrong. Enterprise Project Management Main Page

Here are the three causes we often find in our review of clients’ failed projects.

Failed Projects: A Vague Scope Statement

Lots of projects have weak scope definitions. But on failed projects, the scope is so vague that it establishes few limitations on what is included in the project. So scope creep is rampant. People at all levels in all functional areas add new features to the project every week. Here are some examples of additions: new software that the IT department wouldn’t give them; new equipment that didn’t meet the capital approval process; other “goodies” that are good ideas but don’t create value for the project. Project Failure Warning Signs

The scope has to define specific deliverables the project must produce. That scope of the project must be approved before any work starts. The scope statement itself must include quantified acceptance criteria. These are metrics that can be objectively measured. As an example, a customer service improvement project might have a scope of “Less than 3% of the customers have to call back about the same problem.” That metric gives the executives, the sponsor and the project manager a tool to judge whether user requirements and change requests are necessary to produce the deliverable.

Failed Projects: Lack of Data in Planning and Tracking

Another characteristic of failed projects is project plans without data. They don’t have estimates of the hours of work required for the tasks and deliverables. Instead, the sponsor plucks a completion date that sounds good out of the sky. Cost estimates are also missing except for general wild guesses. As a result, people who are completing tasks or purchasing items have no constraints on the time or money they spend. This is bad enough during planning but it is disastrous when it comes to tracking actual results. Team members’ status reports don’t give the number of hours and dollars they have spent on their task and an estimate of the hours and dollars required to complete their tasks. Instead they give a subjective estimate like “I’m in greenlight status.” This doesn’t give the sponsor or project manager any ability to decide where the project’s problems are or even if they exist. Project Rescue

Failed Projects: No Accountability for Results

Finally, failed projects have little or no personal accountability for results. Some team members are working on a specific task. Others are part of a more general effort involving the entire project team. But few team members are held accountable for producing a specific deliverable, by a certain date, for a specified number of hours or dollars. As a result, it is impossible to identify who should solve a problem on a task.

Failed Projects: Summary

Here are the characteristics that all failed projects have in common:

  • They take place in organizations that have no standard project processes
  • The scope of these projects are vague
  • There are no standard planning, tracking and reporting processes
  • All projects are ad hoc. Each project manager makes up the rules about how to manage their project
  • No one is held accountable for delivering results

Organizations won’t change their project management processes until the pain from failed projects is too great to ignore.

Learn how to use project management best practices and avoid failures in our online project management basics courses. You work privately with an expert project manager. You control the schedule and pace and have as many phone calls and live video conferences with your instructor as you wish.  Take a look at the course in your specialty.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=”00000000″]Consulting Projects[/button]

Lean Project Management

Dick Billows, PMP
Dick Billows, PMP
Dick’s Books on Amazon

One day you emerge from your Performance Improvement Project status meeting and realize your once “lean and mean” project is waddling toward the completion date. It’s destined to be late for lots of reasons.  How could this happen? You started out with Lean Project Management but then...

  • The engineers fell in love with a new nano technology that was critical to the first deliverable. But now they’ve added it to four more deliverables.  That added a few extra days of development and a few more of testing, then another few on installation.
  • You lost a couple of arguments about a “Do-it-Yourself” report generator that two stakeholders raved about.  You were willing to bet they would never use it but eventually they went to their boss about it. Then you got a phone call from the sponsor about the need to keep the stakeholders happy.
  • The sponsor insisted upon adding a training class to the project. He wouldn’t listen when you tried to explain that the class would delay the completion date.  The sponsor told you, “Find a way; use your leadership skills.”

Now your once lean project is a fat pig. Stakeholders want to talk about features, functionalities and fixtures, not the business value they will deliver.  Planning the project is difficult when executives talk about “getting started quickly” and finishing “as soon as possible.” They think you can plan the project as you go. Project Methodology Main Page

Lean Project Management: Techniques That Don’t Work

A never-ending stream of changes and additions make it difficult to stop projects from adding fat. So how do you cope? Well, there are a number of techniques that don’t work.  The first “sure to fail” tactic is to write long, rambling project scope statements that are so vague no one disagrees with anything in them.  This makes the stakeholders very happy with you…in the beginning.

The second “sure to fail” tactic is to focus on features, fixtures and activities. This delights the micro-managers in the stakeholder group as well as people who want to avoid conflict and making difficult decisions.  This last group is easily identified because they’re the ones who only talk about getting off to a fast start.

Lean Project Management Techniques That Do Work

We’ve talked about what doesn’t work. Now let’s talk about the lean project management techniques that do work because they let you “frame” the project.  You need to get all the project stakeholders to look at the business situation through the same frame. Then they must agree on the dimensions of the frame which are the project’s business value.

lean project managementA Short, Direct & Measured Broad-Brush Plan

Long windy narratives don’t give you the kind of framing you need because people don’t read them and the frame has no hard edges.  These “literary masterpieces” define the scope with such political correctness that everybody can see something in it they like.  What works best in lean project management is a short, 1 -1.5 page, broad-brush strategic plan that frames the measurable and verifiable business outcomes and the value of the project.  You can always write a more massive plan once the strategic framing is approved.

In lean project management, you must do the difficult thinking that’s required to frame the project in terms of measurable business results. You must resist talking to project executives about the  technical details of the approach that you’ll use. Few project sponsors are interested in the technical details of coding languages or design strategies.  Project managers who talk to sponsors at this level should not be surprised when they have difficulty getting the executives to meet with them.  Regardless of how fascinating you may find the technical details, most project sponsors are not interested in how you get to the end result.  They don’t care about the nitty gritty details.  They like the lean project management approach of what people will pay for the product and how many the Sales people can sell.

That’s why lean project management requires you to do the difficult task of probing the business situation and quantifying the project outcomes and the business value of the project. You must find out what business value the sponsor wants the project to produce. For example, it can be a new product or a solution to a problem.  You must express that business value in the sponsor’s language, not yours.

Spraying Gasoline on Smoldering Embers

Good strategic project framing doesn’t create conflict.  But if burning embers of conflict exist in the business situation or between the sponsors, good project framing sprays gasoline on those embers to ignite them.  Why inflame the conflict?  Because you’d much rather bring it out into the open before you start work than have the flames spring to life when the project is half done. We’re not talking about you having conflict with the sponsors.  That would be a stupid, career-limiting move. These people are your clients or organizational superiors.  No, we’re talking about inflaming the conflict between the sponsors and then facilitating its resolution before you start work on the project.

So how do you inflame this conflict? By being absolutely crystal-clear about what the project will produce and, as importantly, what it will not.  You do this with a short scope statement that is unambiguous and states measurable business outcomes.  That’s the gasoline and you spray it on the fires of conflict by distributing it to everyone in a very short, direct and readable form.  You want them to agree on how they will measure success when the project is done.

Decomposing From the Top Down

Once you have the sponsor’s agreement and sign-off on the measured business outcome the project will deliver, (the scope), you start the decomposition effort.  This process develops a network of supporting sub-achievements that will lead from the present business situation to the Measure of Success (MOS™). Once again, you’re spraying gasoline on any conflicts that exist by being very specific, quantifiable, and measurable in describing the supporting business achievements that will lead the project to the end result. This path to the MOS™ includes more than just your work.  It also frames the process changes and achievements that other people in the organization must deliver.

The difficulty in this process is avoiding the “activity trap.” Everyone (including project managers) finds it easier to talk about what they’re going to do than to define what they’re going to achieve. But when the backbone of your project is laid out in measured achievement terms, you frame the project for the stakeholders and create a foundation for crystal clear assignments to your team members.  You can communicate to the team exactly what end results you expect from them before they start work.

4-Corners™ Trade-Offs     lean project management

Now you’re ready to develop the “4-Corners” of your project plan and give yourself the best scope and change control tool available. That is the ability to quantify trade-offs between the four dimensions of the project.  Every project has “4-Corners” and changes in one corner always impact at least one other corner:

  • Business value (scope)
  • Budget (cost)
  • Completion date (duration)
  • Level of confidence (risk) in delivering the preceding three corners.

Unfortunately, in most projects only one (or two at the most) of these corners is explicitly measurable.  The completion date is always objectively measurable and usually rock solid.  But most internal projects have no other measurable dimension.  In some business situations, the budget for the project will also be measurable.  But even with these two measured dimensions, the business value of the project is usually unmeasurable mush.  As a result, you can’t quantify the impact of scope changes on the budget or duration except by whining loudly.

The risk corner is rarely measured. As a result, project sponsors assume there’s no risk and you are 100% confident of delivering the business value within the duration and/or budget.  Now 100% confidence seems ridiculous, particularly in light of the fact that most organizations experience a project failure rate near 50 percent.  Yet few project managers give their sponsors the opportunity to make decisions about the level of confidence they want and the level of “risk insurance” they’re willing to pay for.

The lean project management framing process we’ve been talking about gives you a scope.  You can use that quantified measure of the project’s business value when you build your project schedule and budget.  You can also present your sponsor with quantified trade-offs between the “4-Corners” of the project plan.  This data-based decision-making and “fine-tuning” is a far better approval platform than one based on arbitrary changes to one or more of the corners without any compensating changes in the others.

You will use these quantified trade-offs every time there is a variance to the plan.  Your lean project management status reports will include trade-off analyses between the “4-Corners.” That allows executives to evaluate alternatives for taking advantage of opportunities and recovering from problems.


Learn more about our Lean Project Management Methodology and the specific techniques for framing your projects and developing “4-Corners™” trade-offs in our online project management courses. You’ll work privately and individually with a expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish. Take a look at the course in your specialty. We can also customize a program for your organization and deliver it at your site or in online webinars.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” color=”red”]Consulting[/button]

Get free articles and videos like this every week

Lessons Learned on an Agile Project

Lately, the Agile Project Management approach has become very popular, and it seems that everyone is a scrum master. Here are lessons learned on an Agile project for every project manager. Now I have to disclose to you that I am not a certified Agile PM. I’m sort of a fan of the traditional approach, but more and more, Agile is taking over. What I would like to share with you today is a bit of a lessons learned from my first Agile project. Project Methodology Main PageLessons Learned on an Agile Project

First of all, Agile PM does not mean that we don’t have to plan, or that we can slack off on documentation. On the contrary, I want to warn you not to underestimate these two aspects of project management. When I was asked to take over one of our “projects in distress,” the project was three month behind schedule and the cost to implementation ratio was deep in the red. Our consultant had sold the idea of Agile PM and my company followed it. For the first three months of the project developers were talking to functional users and going through implementation cycles. The users rejected the implementations because something was missing or incorrectly implemented. Needless to say, there was not much documentation available. So when I took over this is what I did:

1) Organize a user training program about Agile Project Management. Being a newbie to Agile myself, I reached out to my colleague who had experience in Agile PM and we organized user training about this topic. We explained how Agile works, what we expected from users in terms of user story documentation, and what we would expect from our consultants. It turned out that this was a very important step because most of our users had no idea what a sprint was (gathering people involved in the project to focus on its development) and what was expected from them. Agile Project Management

2) Using elements from the traditional project management approach, I redefined and documented the sprint cycles, communications plan, and general project structure. As a result, each sprint now required an official sprint scope document that clearly outlined which topics were in the scope for the sprint. Moreover, I established clear deadlines for submission of user requirements and specifications. The goal was to establish a fair environment for both the functional users and the developers. I expected the users to tell me what they needed, I asked for agreement between functional users and developers on what was possible in a sprint, and I expected the agreed-upon scope to be implemented.

3) If you work in implementation sprints, it is easy to loose sight of the big picture. So I created a diagram that visualized the expected project objective and all user stories had to contribute to that goal. Project scope must be managed all the time.

Using elements from traditional project management, my colleague and I were able to turn that project around and I’m quite confident that we will end it with success. So what are the lessons learned? Even if you are not a certified Agile PM, you can manage an Agile project. Many aspects of a traditional project management approach should be used in Agile too. Planning might be a little different under Agile but it is still necessary. And so is scope management, communications management, procurement management, and cost controlling.

Until next time.

Practical Project Methodology

A practical project methodology is a set of instructions and steps for people to follow in doing a project. There is great advantage to the organization from having a methodology which is followed on all projects. This does a couple of things for the organization:
1. Every executive who sponsors projects and everyone who works on projects will have a consistent set of rules to follow. That saves time on every step because you don’t need to figure out how to do it; you don’t need to reinvent the wheel.
2. A methodology allows the organization to control how resources are used on projects. The methodology usually includes a procedure for initiating a project and securing some level of approval for using company personnel and money. Project Methodology Main Page
Those two very important benefits are often not realized because the methodology that is developed in the organization is not practical. A frequent flaw is too many forms, too many meetings and too much wasted time on bureaucratic procedures.  This added level of bureaucracy has project managers asking executives, “Do you want me to do the project or fill out all these damn forms?” The way to avoid this is to have practicing, practical-minded project managers develop the methodology. The goal of the methodology is to standardize things, not make everybody a better project manager.

A practical project methodology and project best practices are a minimum requirement for project success but not the key to success.  The people are the key to success and a practical methodology considers this.  A methodology is most  useful when working on critical projects, or when you need to improve the general health and performance of the organization in running projects.  But too often the methodology does little more than create burdensome paper work.

practical project methodology
Following a project methodology

This practical project methodology is based on my experience and lessons learned from failures.  A  methodology should be simple like “adding eyes and ears to watch your back.”  As trivial as it may sound, it can save the day.

A project is an ad-hoc organization with clear goals and accountability structure. The PM and Sponsor are ultimately accountable and must  leverage the resources the organization has allocated and achieve the specific scope. We have project failure when the accountable individuals don’t have a simple methodology to follow. In many cases it fails from weak scope management which is a result of weak stakeholder management. In other cases it fails from PM’s getting overwhelmed from the tracking activities, managing communication and loosing the big picture (like missing the forest when looking for the tree).

However, I have seen projects where a complex methodology was followed by the book and still failed. It failed because the sponsor and PM failed to gather together a group of high energy, responsible people who could enforce the plan and oversee the daily activities. My experience is that the most important aspect for these people to be effective is the right combination of energy and responsibility. At this task, even someone fresh from university, but with the right biology can be a much better team member than an experienced person. As a closing point, making sure to involve the right persons in regards to the character traits is the first, and maybe most important, step to improve project performance.

PMOs Project Management Offices Usually Fail

Work Breakdown Structure
Dick Billows, PMP

Why PMOs – Project Management Offices – Fail

Project Management Offices (PMOs) often fail to improve their organization’s project success rate. Most frequently, the PMO either tries to impose pointless paperwork on all the project managers or it gets no executive support for changing the way projects are done in the organization. With either of those barriers, the project management office is doomed to fail.
We tell our clients who are considering a PMO PMP PDU“the pain of project failure must be severe for you to succeed with a project management office.” We’re trying to communicate that the sacrifices and restrictions that come from an effective PMO are painful. They are painful for executives who lose some of their decision-making prerogatives. They’re also painful for project managers whose work is more closely scrutinized. So to get the necessary support, the organization’s pain from project failure has to be much worse than the pain from establishing an effective project management office.  The organization is ripe to establish a PMO and make it work immediately after a large project failure that affects many parts of the organization.

Why Creating an Effective PMO is Hard To Do

One of the things that makes a project management office or PMO so hard to get off the ground is that you must start by controlling the initiation of new projects. Uncontrolled initiation of projects is almost always the major problem in organizations that have poor success rates. That is defined as 70% of projects fail to deliver their scope on time and within budget. There are simply not enough resources to complete all the projects that are started. What we consistently find is that when managers and executives who want to launch a new project are required to explain and commit to the business benefits that will result, at least a quarter of the projects vanish.

PMO Must Control Project Initiation

While this early success in controlling initiation looks good, it does not do away with the fact that the process will eventually restrict the ability of executives and managers to start any project they want. This is a bitter pill for many of them to swallow. However, it is absolutely necessary for the organization to identify the business benefit of all new projects.
First, the organization needs to eliminate the projects whose benefit is far less than their cost. Second, identifying the business benefit is also the basis for setting project priorities and that is the basis for the allocation of resources. Organizations that can’t properly allocate resources are unable to complete strategically significant projects. Why? Because those large strategic initiatives are starved for resources by all of the “puppy” projects that are launched in large litters every year.  how to pass PMP exam first tryBringing the initiation of new projects under organizational control is exceedingly difficult. What we’re fighting here is the executives’ belief that because of their rank they can start a project whenever they wish. Their belief that they can start a project using their own subordinates whenever they wish is especially strong. But an effective PMO must control the initiation of projects across the entire organization. That is the only way to prevent wasting resources on projects that produce little benefit.  We often encounter situations where organizations have skipped controlling initiation because it is so difficult. The project office never succeeds when that step is avoided.

PMO Must Set Project Priorities

The second most difficult thing in beginning a PMO is setting project priorities. What this means is that senior decision-makers have to sit down periodically and decide which projects get “first call” on the organization’s human and financial resources. These meetings can be very nasty in the beginning. Hostility and conflict between functional divisions of the company make compromise and bargaining difficult. However, after the executives have met three or four times, they all realize that it’s important to make bargains and set priorities. Specifically, the way to play this game is to have everybody around the table owe you because you’ve made a compromise so they can get one of their projects ranked highly. If each executive behaves that way this process becomes very smooth. All project-based organizations (organizations that make their living doing projects like consulting firms, accounting, engineering, architecture) are effective at allocating resources. With some coaching and counseling, most executive groups can make this prioritization a smooth running weekly process.

PMO Must Allocate Resources

With projects having to pass a business value screen before they can be initiated and with project priorities set, the rest of the PMO is comparatively easy. The vast majority of organizations use the desktop PC to combine the project plans and allocate resources to them based on the priorities the executives have set. On a regular basis, all of the “project people” in the organization get a schedule of which project(s) they’re going to work on. As part of the allocation process, a ceiling is set on how many hours of project work a line manager or supervisor can be assigned. That’s because everyone wants them on their project teams. Emergencies certainly come up and there are crash projects that have to start immediately. The mechanism in place to allocate reproject officesources allows the PMO to make changes to the priorities and reallocate the resources when there is a project that must be staffed immediately.

PMO Must Report and Solve Problems

The most publicly visible part of the PMO is turning out data on the status of projects. This requires the implementation of a reasonably standard project management methodology and regular reporting by team members. The key to early identification of problems is to have all team members report not only how many hours of work they completed on their task but also how many hours of work remain. With this “estimate to complete” data, the PMO can identify problems early and take corrective action while the problems are small.

PMO Must Have a Project Management Methodology

 Organizations need a scalable project management methodology. One size does not fit all. Small projects that are only going to take a couple of weeks don’t require the amount of documentation and planning that a six-month effort with a dozen people needs. Three levels of project methodology are sufficient for most of our client organizations.  They share some common elements even though the scale is different. First, they don’t have project “to do” lists. Project planning is more effective and efficient when the plan is based on deliverables. Team members have a deliverable that is clearly described and they are held accountable for producing it. This is much better than trying to tell them everything they have to do. The only exception to this approach is for a brand-new employee or trainee who obviously needs much smaller assignments so they can learn their job. But if all projects are planned with a consistent methodology, the initiation of new projects, the setting of priorities, the allocation of resources and the tracking of problems can all be done smoothly and effectively.
Learn how to effectively manage multiple projects and set up a PMO in our Managing Multiple Projects course.

Project Change Control – Video

Dick Billows, PMP
Dick Billows, PMP
Dick’s Books on Amazon

When project managers handle project change control badly, it irritates stakeholders and cause overruns on budget and duration. Fighting all changes doesn’t work and neither does accepting all of them. We’ll discuss the mistakes project managers make on change orders. Then we’ll review a methodology for doing it the right way.

On many projects, the project manager faces a never-ending stream of additions and changes.  These begin five minutes after the sponsor approves the project plan and continue until five minutes before they accept the last deliverable.  Watch this video of a typical change control process.

Project Budget - How To Handle Budget Cuts

A Project Change Control Story …

Walking out to the company parking lot, you ran into the executive who was the sponsor on your current project.  The sponsor said, “The project is really coming along well but I do need to add a couple of things.” They handed you a page from a yellow notepad with 35 items on it.  You knew it was time to exercise project change control. But the sponsor continued, “These items are really vital to what we’re trying to achieve on our project.” How to Manage Change Order Requests

You looked down at the paper and replied “We couldn’t possibly make any additions at this point.  The due date and budget are in danger now. If we keep adding things we’ll be way over.”

The sponsor said, “But these are critical! Without these additions, this whole project will certainly fail.”

You responded, “I think the project will contribute a great deal even without these items.”

The sponsor disagreed, “These were really part of the original requirements.  You must have missed them.”

You replied, “I’m sorry but these items were definitely not on the original list of requirements you signed.”

The sponsor grew re-faced and retorted, ”These were part of the business plan for customer service.  I don’t care what was on that long list of technical mumbo jumbo you designed.  It was just geek talk that none of us understood!” Scope Change Video

You looked back down at the list and tried to calm the sponsor by saying, “Anyway, these seem to have limited business value.”

The sponsor barked, “I’m the one running this operation and I know what’s necessary. And the items on the list are essential if we’re going to maintain competitive levels of customer satisfaction.”

You took a deep breath, “We will be late if we add anything.”

The sponsor took a breath, smiled and said, “These items really won’t take much work. So they should only hurt the schedule or the budget a little.  I know you can squeeze them in.”

Project change controlYou frowned, “That is not the case.  We will have overruns. They won’t be my fault because these items were never in the approved requirements.”

The sponsor snapped, “If you won’t add these items to the project schedule, I’m going to bump this problem up the line to the VP.”

Project Change Control with Several Endings…All Bad

At this point, the project change control story could have several endings. Why Is a Scope Change Process Needed?

1. In the first ending, you said, “OK your satisfaction is my goal.  We will figure out a way to squeeze these in and not finish too late. But these must be the last changes we make or we’ll have a disaster! “

The sponsor gave his solemn promise, “Absolutely! These are the last changes.” (If you’re naive enough to believe that, you can forget about project change control.)

The next week the yellow sheet of paper had 47 additions, the project finished 3 months late and you took the blame.

2. In the second ending you refused to add the additional requirements.  Five hours later your boss called and angrily said, “The senior VP just chewed me out about my project managers not being responsive to our management team. Why are you stirring up trouble with your sponsor? We need his support!”

You started to explain about the changes to scope and the boss interrupted saying, “Add the damn changes…just get these people off my back.” You started to agree just as the boss slammed the phone in your ear.

The next week the yellow sheet of paper had 47 additions, the project finished 3 months late and you were blamed.

3. In the third ending, the boss listened as you said, “I’m trying to be customer-oriented but those changes could set us back a couple of months and cost lots of money.”

The boss said, “Give me a memo on exactly how much later and how much more it will cost so I can show the vice president.”

You thought for a long moment and said, “Well, it’ll take quite a bit of time to put that together.”

The boss grunted in exasperation and said, “I need something to show the vice president today.  So you’d better just add the changes they want and have everybody work harder. Use your leadership skills.”

The next week the yellow sheet of paper had 47 additions, the project finished 3 months late and you were blamed for not exercising project change control.

Why Does Bad Project Change Control Happen Over and Over Again?

It happens because project managers lack the tools to exercise project change control. One key to project change control success is project planning that develops quantifiable acceptance criteria for the project scope and each major deliverable. These are not technical specs but measured business outcomes in the customer/user ’s organization.  Those acceptance criteria with metrics are the foundation of project change control. That kind of scope definition lets you win the argument about whether changes are necessary for project success.  That type of scope metric makes the argument about what was and what was not included go away.  Everybody knows what was originally included. Then you aren’t arguing the merits of a change or whether it’s a good or bad idea (you will always lose those). Instead, you are discussing whether or not you can achieve the scope without including the change.

The second key to successful scope and project change control is using a software tool that allows you to quickly quantify the impact of a change.  You can use the software to quickly estimate, and then model, exactly what effect a change will have on the project’s cost and duration.  With this modeling capability, the conversation with your customer/user is quite different.  Let’s see how it goes using both these tools for project change control.

Project Change Control the Right Way 

The customer stepped into the your cubicle and said, “The project is really coming along well but I need to add a couple of things.”  They handed you a page from a yellow notepad with 35 items on it and then continued, “These items are really vital to what we’re trying to achieve on our project.”

You looked down at the paper and said, “These are great ideas. OK, let’s quantify the added work and the added time.” The customer’s first item was additional training for customer service reps so they could discuss three new products with customers.  You said, “We would have to change the training achievement from “Customer reps can answer questions about 37 products accurately 90% of the time,” to ’40 products.’ I’ll ask the trainer to give me an estimate of the hours required for the change.” You called the trainer who gave you a rough estimate of 12 additional hours of prep time on the new products and 15 additional hours of class time.

While you were writing, the customer said, “It should only take a few more minutes. Anyway, I thought these new products were in the original specs.”

You pulled out the plan for the deliverables and said, “No, here is the trainer’s work package we used for the estimate. It has 37 products.”

The customer agreed the new product training was not covered in the original project scope and plan.

You commented, “If you want to eliminate three of the original products, it would be a wash.”

The customer responded, “No, we need all 40.”

You said, “The trainer says that will add 27 hours of their time and the class itself will be longer for the attendees. You opened the project schedule on your PC and entered the additional hours. Then you leaned back and said, “As you can see, these changes would add 7 days to the project duration and would increase our costs by more than $16,000.”

The customer was surprised at the cost and said, “But these are necessary. They are good and worthwhile additions.”

You smiled and said, “I’m sure they are very good ideas or you wouldn’t have brought them to me.  But our question has to be; can we hit our project’s measured achievement of, “Customer reps can answer questions about 37 products accurately 90% of the time” without them? They clearly expand the project scope and I will need to add extra time and money to accomplish what you want.  That’s how project change control works.”

The customer said, “Well, I want you to include these items in the project or I will escalate the problem to the senior VP.”

You smiled again and said, “That’s appropriate because in our project change control process, it is the senior VP’s role to approve changes of this size. We have the data now so let’s go speak to the VP. We’ll ask if she is willing to expand the scope and add the cost and duration of your change.  But I’ll be honest with you. I don’t think we need any of these changes to hit the original scope we committed to for this project.  It’s nothing personal. I’m just trying to exercise project change control.”

A Consistent Project Change Control Methodology

You need the right tools to do project change control correctly and that means a consistent methodology. The methodology begins with the initial planning of the project and gives the you tools and processes to identify the measured business achievements the customer/user wants the project to produce. This is not just the technical specifications.  The project change control methodology guides you step-by-step through the development of a dynamic schedule and budget.  Those tools allow you to quickly calculate the impact of a change order so you can exercise project change control.  This methodology is also used in status reporting. You do the same modeling to calculate the impact of the corrective actions that are needed to solve variances.

You can learn a methodology to effectively manage project change control in our Project Management Basics course. It is private online training where you have as many video conferences and phone calls with your instructor as you need.

Enterprise Project Management

Dick Billows, PMP
Dick Billows, PMP
Dick’s Books on Amazon

When we talk about enterprise project management, we’re talking about the processes organizations use to initiate, plan, monitor and control, track and close projects. We also include processes to prioritize projects and allocate resources to them. Quite simply, enterprise project management is an organization’s way of doing projects. At a minimum, these processes should include:

1.) How the organization initiates projects

2.) What criteria each project needs to meet to be approved

3.) Assignment of a priority for using organizational resources.

That priority allows the important strategic projects to get first claim on the organization’s resources. Projects with a lower priority have to wait until the high priority projects have the resources they need. The organization should also have processes that project managers and sponsors follow as they plan, schedule and track their projects. That gives the organization’s enterprise project management consistent language, plans and reports. It allows everyone to work together more effectively. Evolution of Project Management in Organizations

A consistent approach produces significant benefits across all projects in terms of people understanding the role of the team member, sponsor, stakeholder and project manager. The role each of them plays is standard in terms of the decisions they make and the accountabilities they have on the project. Those consistent roles and processes allow for executives to become accustomed to the format of a project plan and a proposed schedule. That allows them to be more efficient and exacting in their review of projects.  This doesn’t mean the organization does every project exactly the same way. Most organizations have an enterprise project management protocol that differentiates between projects based on their size, scale and strategic significance. So in most enterprise project management protocols, small projects do not need as much paperwork and documentation as larger projects.

Enterprise Project Management Protocol

The enterprise project management may have a basic protocol for small projects. The project plan may be a short document with fewer than six elements such as: scope, requirements, estimates, resources, schedule and optimization. They include little, if any, risk management and the project has no additional quality processes beyond what is standard in the organization. Status reporting is very straightforward, consisting of identifying variances and explaining the proposed corrective action.

As projects get larger, the project plan grows to cover more topics. Risk management becomes increasingly important so they implement a risk management process with risk identification, qualitative analysis, quantitative analysis, risk response planning, risk tracking and monitoring. There is a formal risk response for each identified risks along with contingency plans if the risk response does not prevent the risk from affecting the project. Is Your Project in Trouble?

Organizations without enterprise-wide processes for completing projects have lower project success rates. They also have trouble getting the most important projects completed on time and within budget. Even worse, the lack of consistent project processes creates chaos in the trenches. Project managers battle each other for team members and no one manages people’s priorities and workloads.

Organizations with project failure rates above 50% have trouble surviving, particularly in tough economic times. But their efforts to improve performance often fail because they aim at the wrong problems.Why Do So Many Projects Fail?

Based on our experience with over 300 organizations, there are four keys to improving an organization’s project results.

1. The organization must control the initiation of new projects. Managers and executives can’t start a new project whenever they wish.

2. The organization must prioritize the projects so the major strategic initiatives get the resources they need.

3. The organization has to allocate resources to projects based on the priorities they have established. Without this, hundreds of “puppy projects” that produce very little benefit will use up to 40% of the organization’s project resources.

4. The organization has to use a consistent methodology for all projects that is scalable for the size and importance of the project. If not, small projects will be buried in too much paperwork. Project Failure Warning Signs

Enterprise Project Management Protocol Implementation

Implementing the enterprise project management protocol is a major effort. Project menterprise project managementanagers, sponsors, stakeholders and team members need to receive some level of training on how to play their roles. Organizations also face the problem of “cleaning out the pipeline” of in-process projects that have not been managed according to the new protocol. Often times the best approach is to simply let these projects wash themselves through the pipeline. But all projects started after a certain date must comply with the enterprise project management protocol. How to Implement a Project Management Protocol

A major implementation issue is the sophistication of the project management processes. The temptation is to go too far and insist on more project management processes than necessary. The protocol then takes too much time and people don’t do it. When organizations and their project managers go overboard with exceedingly complex processes, they get less than 10% compliance. It is better to adopt a simple system that requires relatively little additional time from sponsors, project managers and team members. The organization should implement a bare-bones enterprise project management protocol and use it for one year. After that time their executives, project managers and everyone affected by it is better able to discuss what could be added to or deleted from the protocol. They decide what to add by comparing the value of the additions to the amount of time and money they would require. Project Management Office Types

You can learn more about implementing an enterprise project management protocol in our online project management courses. You work privately and individually with a expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish.  Take a look at a course in your specialty.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” color=”red”]Client[/button]


Get free articles and videos like this every week





Project Management Process

Dick Billows, PMP
Dick Billows, PMP
Dick’s Books on Amazon

Organizations realize many benefits when they have a project management process that is consistently used by all the project managers in the organization. The process does not require a big investment in software, although some components are best done with automation. Many companies do the whole project management process on a PC. But the technical aspects are the easy part. An effective project management process gives executives control of the entire portfolio of projects and guides decision-making at all levels. Crafting the right decision-making processes for your organization and then training the executives, project managers and team members to play their parts correctly is the hard part. Enterprise Project Management Main Page

Steps in the Project Management Process

As an overview, project management begins with initiation of new projects. That is the biggest weakness in most organizations. In an effective project management process, the initiation steps include a brief document of the project’s costs, benefits and its justification. This allows the organization to make decisions about which projects to do and avoid spending time and money on losers. The one page initiation document also allows the organization to set priorities and then allocate resources based on the benefits of a project. Project Planning

Next, the executives and project manager build a project plan using templates the organization provides to minimize the paperwork. The templates also provide consistent project plans and schedules.

The last part of the process is monitoring with weekly status reporting on all projects. This provides central identification of problems and variances so they can be corrected. It sounds simple and it should be to get people to comply. How to Write a Weekly Status Report

The objective is to ensure consistency in how project managers initiate, plan, execute, monitor, control and close their projects. This is not to say that every project will be identical. However, a reasonable degree of consistency allows executives to be more efficient in reviewing project plans. It allows project managers to archive data and that is a key element in improving the organization’s project management results.

Key Components of the Project Management Process

A project management process can include many components. First, the system may provide templates project managers use to develop their business cases, project charters, project management plans, estimates, risk analyses, cost estimates, duration estimates, human resources plans, etc. The idea behind using templates is that the organization of the information is consistent across all projects. Using templates also facilitates archiving the project data for later use.  Project Plan Template

Second, consistently successful organizations don’t reinvent the wheel on every project. They archive project data and use it on subsequent projects. This requires archiving data on the actual amount of work tasks took versus the estimated amount of work. That data can be in the form of a completed work package, “lessons learned” documentation or it can be automated. In either case, the information is available for project managers to use on new projects. It can also include the risk analysis, procurement statements of work and requests for proposals from vendors on previous projects.

project management process

Accessing Data From the Project Management Process

As a  project manager starting a new project, you must put together a great deal of information. You can save a great deal of time if the organization has a mature project management process. You can start by going through the archives of previously completed projects to identify ones that are similar as a whole or that have major deliverables similar to what you anticipate in the new project. Then you evaluate that data from the previous projects.
For example, let’s say one of the archived high-level deliverables was a modification to a financial system that is similar but a bit simpler than the modification required for your new project. That doesn’t mean you can’t use the data from that project. It simply means that you’ll have to adjust the work estimates upward to account for the additional complexity of the new project. You’ll also review the risk analysis from the previous project to see if any of the risks, analyses and responses can be used on your new project. Additionally, you’ll review any procurements, stakeholder analysis, human resources plans, etc. to determine if you can modify the work previously done and save a great deal of time. Lessons Learned Documentation

Implementing a Project Management Process

As organizations strive to improve their project performance and become consistently successful, one of the least expensive steps that produces significant benefits is implementing a project management process. This requires the project sponsors and project managers to agree on the steps and templates to be used as well as the data elements to be archived in the system.  The use of templates and archived data have the largest impact and start paying benefits in as little as three months. Other elements can be added to the project management system to achieve consistency in status reporting, scheduling, variance reporting and change control.

You can learn more about using an effective project management process in our online project management courses. You work privately and individually with a expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish.  Take a look at the course in your specialty.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” color=”red”]Client[/button]

Get free articles and videos like this every week

Project Lessons Learned

The project lessons learned process is ineffective in most organizations. One project after another suffers from the same mistakes.  What is even worse is that the bigger the project failure, the less likely they are to learn from it.  The same issues that cause a project to fail also prevent the people involved from learning from the failure. Organizations need processes to make sure they don’t relive project failures. Let’s take a look at a typical project lessons learned session and then talk about the right way to do it.

Dick Billows, PMP
Dick Billows, PMP
Dick’s Books on Amazon

Project Lessons Learned: Poking Through the Wreckage

You shuffled into your project lessons learned session, sick and tired of political games and finger-pointing. Twenty minutes later, you trudged out with the voices still echoing in your head:

  • “You’re responsible for us finishing late!”
  • “Me? You kept making changes. I’m surprised we ever finished!”
  • “You still aren’t finished; the garbage you gave us still doesn’t work!”
  • “What? We gave you what you asked for! But you didn’t train your people to use it”
  • “They need PhD’s to use what you built!”

You walked down the hall knowing this was your fault.  Sure, there were a few jerks involved and it would be easy to blame them. But a good project manager should be able to structure things to make even the jerks productive team members.

Even though scenes like this repeat themselves after every project, many organizations don’t improve their processes for doing projects. The same problems wreck one project after another.  But there is an alternative. What you need is a lessons learned process that gives the project managers an opportunity for continuous improvement.  The time you invest in your lessons learned process can positively affect projects that are underway. It can also reinforce the use of a consistent project management methodology.  You build the project lessons learned process in the following three stages. Lessons Learned Project Management

Project Lessons Learned: Stage 1 – Pre-Launch Peer Review

Our 4PM clients have increased their success by using peer reviews of projects that are nearing launch. That sounds fancier than it is. In this first stage of the project lessons learned process, project managers get feedback on a their plans from other PMs.  They have a meeting (in-person or online) to discuss a recent plan. That gives PMs the chance to share ideas and renew their understanding of the methodology.

The pre-launch stage is a busy time for project managers but it’s also the point at which correcting mistakes is least expensive.  The process is straightforward. The other project managers review the user’s or client’s business situation.  Then they Project Lessons Learnedindependently critique the project’s plan, scope, requirements, WBS, charter, accountability structure, team member assignments and the schedule.  Reviewing several project plans doesn’t take the other PM’s very long if the organization’s project management methodology emphasizes thinking , not creating paperwork.

In the project lessons learned session itself, the other PM’s ask questions and offer ideas. The project manager whose work is under review may or may not take them but they get the benefit of the ideas and opinions of other people engaged in the same type of work.  Every project manager suffers from tunnel vision as he or she works through the development of a detailed plan.  The thinking of other project managers who are not buried in all the detail is very helpful.  It’s easier for them to spot any disconnects between the user’s/client’s business problem and the project plan details.  It’s important to keep this conversation focused on “Are we doing the right project for this business problem?” and “Does the planned control process make sense for the desired business result and resources involved?”  The conversation should be at that high level and not sink into a technology debate.

Project lessons learned sessions  are effective in building consistency in the use of a project management methodology.  Compliance with project management standards tends to slip under the pressure of all the work to be done just prior to launch.  But when project managers know their peers will be reviewing their work, they comply at a point in the lifecycle where comments from the project office or standards people might otherwise be brushed aside. These pre-launch peer reviews are ideal for reinforcing the organization’s project management methodology.  You have the right people gathered and you’re dealing with real business situations and projects, not theoretical ideals.  So these sessions are good opportunities to renew people’s skills in using the organization’s project management methodology.

Project Lessons Learned: Stage 2 – Portfolio Management & Change Control 

The second stage in the project lessons learned process is regular (usually weekly) review of project variances. This can be at the end of the weekly status report or team meeting and after you have defined corrective acProject Meeting Rescuetion for the variances. You review the variances again and focus on how to avoid them in the future. You also identify other tasks or people who are likely to encounter the same issue so it can be avoided. The focus is on ways to avoid a repeat. It does not take long to identify the options.

To accomplish this project lessons learned review, the project methodology must give you a reliable method of identifying changes to the approved baseline schedule. You need a methodology that gives you objective measures of project progress plus the work and cost estimates to measure the variance.

Project Lessons Learned: Stage 3 – Project Team Culture and Leadership Style

The last stage of the project lessons learned is the periodic assessment of your leadership style and the culture of the project team. The work attitudes and effectiveness of the team members are strongly influenced by your leadership behavior. Even a professional team may suffer in silence about the project manager’s leadership and not take the risk of providing constructive feedback. Frank feedback is very useful so you have to make it safe for them to give it.

An effective technique is to ask the team to have lunch together once a quarter.  You don’t attend but you ask them to a write a summary of their consensus of your strengths and weaknesses. You should digest the information but not ask questions about it.  Most importantly you should not make them justify any of their negative findings. That makes you seem defensive. Good project managers act on negative feedback and make improvements. Bad PMs can’t handle the criticism so they dismiss it, learn nothing and never improve. Lessons Learned Questions

Project Lessons Learned: Summary

The three-stage project lessons learned process for project management improvement is an important element in moving the organization toward delivering consistently successful projects.  It also can contribute to developing consistently effective project managers.  We include this project lessons learned process in our project management methodology so organizations and their PMs get better over time and don’t repeatedly relive failures.

You can enhance your PM skills and master the project lessons learned process in our online project management courses. You work privately with a expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish.  Take a look at the courses in your specialty.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Client[/button]