Project Management Methodology: Repeat Successes Not Failures

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

It’s important for project managers to understand the Project Management Methodology in their organizations. Here are the five stages organizations go through as their project methodology evolves and reaches project management maturity:

1. Ad-hoc projects
2. Increasing density
3. Resource overload
4. Initiation control
5. Consistent success  Project Methodology Main Page

Knowing how the project methodology stages evolve in an organization can help you be consistently successful with your projects. You can adjust your work efforts (or job hunting) to make the best of the situation.

Project Methodology Stage 1 – Ad hoc Projects

In this stage, there are only a few projects and project management is a relatively new way to get things done. Everyone on the project team reports to the same boss, who’s also the project sponsor. Projects aim at producing benefits within the unit or department. Successes are frequent because good weekly meetings that foster nurturing and commitment in the team are all that’s needed. Sure there are deadlines to meet and other work to do but the boss decides what’s most important for everyone on the team to work

The Weekly Team Meetings Go Like This

Project Manager: “We’ll go around the room so I can find out what everyone decided to do last week. I also want to get your ideas about things we should do on the ‘Paper-less Project’ this week.”

Team Member A: “I think we should add a training class about going paperless!”

Project Manager: “Great idea! Everyone will enjoy that and I think it will really help.”

Team Member B: “Can we also print up big colored posters that tell everyone to “Save a tree, do it on the PC?”

Project Manager: “Excellent! I’ll show the boss these ideas then we can go ahead. We’re a great team with good ideas. No wonder they want us to do another project after this one.”

The sheer enthusiasm people have for the rare opportunity to work on a project makes up for any project management sins. The scope of the project lets the PM work without many project management tools or techniques. People managing projects in this stage can’t understand why PM’s in other organizations have any problems at all. They don’t see any need to learn project management best practices. Organizations may stay in this first stage forever and enjoy high success rates as long as their projects don’t go beyond installing simHow project methodology evolvesple or “canned” solutions. But early successes and competitive pressures usually trigger more projects.  And some of the new projects span functional boundaries and aim for more significant business results. That’s when the organization’s methodology moves to the next stage.

Project Methodology Stage 2 – Increasing Density

As the organization moves into this stage, more managers and executives are initiating projects. The projects are reaching for more significant business results and they involve multiple decision-makers and stakeholders. Defining and controlling project scope becomes a challenge. Projects now include people from across functional or organizational lines. Many people are on several projects simultaneously. This creates conflict for people working on multiple projects. They must balance their project work and their “real” jobs.  Contention for resources also increases. The first line managers in particular are in demand on multiple projects. But they still have departments to manage.  Project managers face the challenge of leading larger teams whose members represent different organizations.  Cross-functional authority problems occur since the project managers don’t have skills in managing matrixed people. The ad-hoc project methodology is inadequate for projects with larger teams and scopes. Consequently, project failure rates rise.
The response to the increased project failure rate is micromanagement by executives and the PM’s. That style makes the projects much less rewarding for team members than in Stage 1.

The Weekly Team Meetings Go Like This

Project Manager: “Did the user sign off on the specifications yet?”

Team Member A: “Yeah, I’ve got 46 pages of them and I’ll be getting more specifications for the next two weeks. This has gotta stop – the requirements keep growing! I have no idea what this project is about and neither does the user.”

Project Manager: “What this project is about is finishing 90 days from now. We’ll figure out the rest as we go. I’ll give everyone new “to do” lists each week.”

Team Member B: “Bill and Marcy got pulled off to work on their boss’s #1 priority project . So I won’t be able to start my stuff until they come back. Can you revise the schedule to give us more time? I’m on six different projects.”

Project Manager: “Oh sure, that’s real likely. The VP ripped my head off last time I even mentioned being late. I’m sorry but you’ll just have to do the best you can. Remember this is a #1 priority project.”

Team Member B: “Yeah, everything’s a #1 priority.”

When the pain of project failures gets too bad, executives respond by training their project managers how to use better techniques. This has some limited benefit but the project managers face an executive group that still operates in the Stage 1 world. They start as many projects as they want whenever they wish. As failures continue, the response is to scale back the large cross-functional and strategic efforts. Decision makers try to dodge the inability to work across functional lines by appointing co-project managers from each functional unit to run projects. Their attempts to avoid authority, priority and resource allocation problems are unsuccessful and failure rates continue to rise. The newly learned project management techniques have little impact on success rates. Executives focus on due dates because they have no other objective control points in the project plans. The unaddressed issues of resource allocation and lack of prioritization cause team member workloads to rise beyond reasonable levels. Executives launch new projects of all sizes without any assessment of their business value or resource demands. The need for strategic, cross-functional results and the scale and density of projects continue to grow, leading us to Stage 3.

Project Methodology Stage 3 – Resource Overload

Here project failure rates climb. Often 70% fail to deliver the scope, on time and within budget. The Stage 3 organization launches so many projects that staffing requirements are three times the actual available resources. Blame avoidance is rampant. The organization begins to lose their best staff members who are tired of the failures, confusing assignments and 70-hour work weeks.

Organizations respond to the crisis by assembling “best practices” groups to try to bring some consistency to the project management process. The usual result is a paperwork nightmare of project and developmental controls with countless forms and reports. Compliance is low and cursory at best. They install subjective tracking and reporting systems, like the red, green and amber light systems. These are certain to fail since they provide very little information and encourage ridiculous optimism in reporting as people try to avoid blame.

The Weekly Team Meetings Go Like This

project methodologyProject Manager: “Is anyone in red light status?”

The project team members look at one another as they all deny being behind schedule. They remember the angry tirades from the project manager and executives the last time someone reported an overrun.

Project Manager: “I haven’t seen the documentation for task #167’s work.”

Team Member B: “Do you want me to write the code as well as the documentation? There’s no time in the schedule for me to do both.”

Project Manager: “Just put something down on paper. That’ll keep the standards committee off my back.”

Team Member B: “What a stupid waste of time! I’ve already got five other projects to work on and I’d like to get home before 10:00 p.m. at least once this week! ”

Project Manager: “Hey, I spend my nights doing variance reports and project narratives that some 9 to 5 pencil-pusher designed to show off his or her project management expertise. Just copy and paste from other projects. No one reads this stuff anyway.”

Organizations move out of Stage 3 only when the pain from recurring project failure becomes excruciating enough for senior management to give up their privilege of initiating unlimited projects.

Project Methodology Stage 4 – Initiation Control

This stage starts when executives realize that they must:

  • Control project initiation
  • Set priorities
  • Control people’s workloads and allocate their project hours based on project priority
  • Actively manage the project portfolio
  • Regularly rate each project in terms of its cost versus the business value produced.

Executives learn to manage within the resource limitations and accept the fact that everything can’t be a #1 priority. They implement a project methodology across the organization that minimizes paperwork and produces hard-edged data for quantified decision-making.

Micromanagement begins to fade as project managers hold team members accountable for clear and measured end results, not To Do activities. The PM’s think more about quantifying the end results they must produce. They also have the tools and techniques to anticipate problems and manage “out in front” of their teams. They don’t just focus on last week’s problems. Additionally, they can quantify the time, cost, risk and quality dimensions of their projects and present trade-off options to the decision-makers.

The Weekly Team Meetings Go Like This

Project Manager: “Well, our project has been dropped down one priority level to free resources for a new project. You’ve all gotten your new schedules and you’ll see that our project is now scheduled to finish 6 weeks later than the original baseline completion date. I’ll keep this meeting short. I just need to meet with Bill to work out a problem. The rest of you are in good shape so you can go.”

Bill: “You want to talk about the variance on task #224?”

Project Manager: “Yes, where did we go wrong on the estimate?

Bill “We got a little too optimistic on the time it would take to interface with that legacy system.”

Project Manager: “Okay, that happens. Can you give me 10 hours of overtime over the next two weeks? That will cut the overrun in half and I’ll add some other resources to the successor tasks to recover the rest of the slippage.”

Moving out of the crisis of Stage #3 is not easy. Organizations need high levels of compliance with a consistent protocol and controls. These give executives the data for assessing each project’s business value, setting priorities and managing resource allocations against those priorities.

Project Methodology Stage 5 – Consistent Success

The last tier of the project evolution comes when all levels of the organization use a consistent methodology and everyone knows their role. This includes a consistent and integrated method of processes and controls that are scaled so they’re appropriate for the size of each project. They measure and track quantified dimensions of each project and manage resources to maximize the business value each project produces. first meeting team

The Weekly Team Meetings Go Like This

Project Manager: “Marcy, thanks for stopping by. I want to discuss modifying your achievement and the work estimate on task #56. I need to develop some trade-off alternatives that will let us finish 30 days earlier. If we cut your response time achievement from “90% of inquiries handled in 60 seconds” to “60% of inquiries handled in 60 seconds,” how much can we lower the work estimate and duration?”

Marcy: “I’ll need to think about it but that would let me cut out 6 inquiry types so we might get a 30% reduction in the hours and duration.”

Project Manager: “Great. Can you give me a final commitment by the end of the day? One of my bosses wants to review the options tomorrow.”

Moving to Stage #5 is difficult. Organizations need to shed the restrictions of the rigid management hierarchy. They also need to initiate techniques that require project decisions and problem-solving to be based on hard data and measured business value for the organization. For IT departments and consulting firms, this methodology is the foundation for strategic partnerships with users and clients that are based on business value.

Learn more about our project management methodology.

At the beginning, 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

Project Management Methodology Development

How to Develop Project Methodology – What Steps Should I Follow? 

As Project Management Professionals, we sometime find ourselves in an Project methdologyenvironment that has no established project management methodology. Instead, what we is inconsistent, and wasteful approaches to managing projects. Some project managers bury small projects in stacks of unnecessary paperwork.  Others manage large projects with no attention to risk management, the proper utilization of resources or procurement.  Still other project managers are so intimidated by due dates that their practices that focus on turning out something, anything (crap) by the deadlines, not on using resources wisely, nor meeting stakeholder expecations. Unfortunately, organizations in those environments are not leveraging their experiences to make improvements in their approach to project management. Enter the Project Management Professional (PMP), armed with PMI best practice approaches and eager to enhance his/her organization’s capacity to adopt best practices. However, the PMP should proceed with caution, do not try to change things overnight or act as someone who has all the answers. Project Methodology Main Page

It’s important to respect the project methodology that is currently in place within the organization. Also, to identify who the main players are and what are their key requirements. Once that has been ascertained, it’s time to start a gradual process to show how improvements in the project management process could add value to the organization’s efforts. Start by getting a clear idea of the requirements of the whole project delivery system within the organization. What are they trying to achieve via the projects in the pipeline? How successful have they been in the past in meeting those requirements? Are they capturing any lessons learned and recording those as an organizational assets? Once those have been determined, it’s time to start a participatory and inclusive process to address the current and emerging gaps within the organization.

I would recommend starting slow and proposing pilot projects that could demonstrate the effectiveness of any new or enhanced project methodology for managing projects. It’s critical to get senior management buy-in on any proposed changes/ enhancements to the current approach. Expect some resistance initially but if you can demonstrate efficiency and effectiveness as outcomes, you will be in a better position to get support and buy-in. It’s critical to remember that any proposed changes should demonstrate clearly how it would add value and close any gaps that currently impede projects being delivered on time, budget and achievement of intended outcomes.

At the beginning of yourncourse, 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


Project Variances, Solve Just the Real Problems

Work Breakdown Structure
Dick Billows, PMP

Project variance is what gives executives nightmares about project failure. They are the calculated difference between the approved project plan’s costs and duration and the actual project results. We can have project variance vs.  schedule where we identified that a task should have been finished by July 1 and it was actually finished by July 5. That’s a four day bad variance. We can also have project variance on the project budget. Let’s say a task was planned to cost $5,000 and it actually cost $4,500 when we were done. That’s a $500 good variance.  Project Tracking Reports Main Page

We can also have project variance on the characteristics of the deliverable and on the planned work versus the actual work. The most important thing about project variances is we do not have to wait until the task is completed to identify a variance. Project managers get information from their team members’ status reports. Using project management software, they take the information about the actual results versus the plan and they forecast variances when the task is done. That allows the project manager to start corrective action before the task is actually finished.

Another major use of project variance is in status reporting to the project sponsor. Having the variance data allows the project manager to show the sponsor how the project is going and what tasks are on schedule and what tasks are not. One of the techniques that separates consistently successful project managers from the rest of the pack is their ability to identify problems early, when they are small and easily solved. Unsuccessful project managers are routinely surprised by big problems that they find out about when it’s too late to fix the damage that’s been done.

The important thing to remember when your project sponsor becomes hysterical about a variance is that we do not have to take corrective action about every variance. If we have a 5 day variance on a task’s forecasted completion date, We do not have to order overtime for the whole team.  If you have used professional scheduling techniques, you will be able to quickly determine if the task is on the critical path and if not how much slack it has. I the task has 10 days of slack you should do nothing about the variance because the slack can absorb it and it will not affect the project completion date. You also need to check if the variance is a signal of a growing problem. But that is an example of when we can ignore a variance.

A few prudent steps during project planning can make all the difference. To spot problems early, you need unambiguous, measurable checkpoints in the project so you don’t have to guess whether you’re on track. With the deliverables defined by metrics, you will know exactly where you are. That’s what lets you take action at the first sign of a problem. Do you want to be regularly surprised by problems when it is too late to fix them or do you want to spot problems early and fix them before they mushroom? How to Write a Weekly Status Report

At the beginning, 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

Project Management Methodology – 3 Tiers to Fit Project Size & Scope

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

A project management methodology is the glue that binds all the organization’s project management processes and techniques. It is a process that helps everyone understand their role and obligations. Without a methodology you can’t exercise control over the portfolio of projects to ensure all of them produce business value and don’t waste financial and human resources. The project management methodology also gives upper management tools to ensure that the organization is doing the right projects in the order of their priority. But project management methodologies often have a bad reputation because of the way organizations implement them.

There are many decisions to be made in implementing a project management methodology. Too often organizations get carried away with implementing advanced project management techniques and methodologies. As an example, the implementers think it’s necessary to apply every detail in the Project Management Body of Knowledge (PMBOK)® from the Project Management Institute (PMI)® to every project.  But when the project management methodology is too complicated, has too much paperwork and too many meetings, people don’t follow it.  The methodo
logy has to make it easier for project managers, team members and sponsors to do a good job.  That’s why organizations need a project management methodology that is scalable to fit the size and complexity of each project.   AdPM Project Methodology

When organizations try to apply a complex methodology to all their projects, they overload smaller projects
with pointless paperwork. This paperwork jungle bogs down project managers and their teams. The extra paperwork, procedures and meetings take so much time that the project managers don’t do the paperwork.  Or they submit the same forms from an earlier project with just a couple of words changed.  This results in the organizations inability to prioritize its projects. And without priorities, it can’t allocate resources wisely.  It also can’t keep track of all the projects and their current status. In other words, there is no organizational project process.

Another result of this overly complex approach is that the organization can’t control the initiation of new projects. People don’t want to do all the paperwork to get a small project approved. So there are a lot of underground projects that are called something else, like “initiatives.” And there are other people who simply start new projects and ignore the organizational approval process. The result is that there is no control over project initiation and a lot of resources are wasted.

Project Management Methodology: Scalable for Three Tiers

The scalable project management methodology is the way you can solve all these problems. It recognizes that small projects need just a small amount of the project management process.  As the projects increase in size, you will add tools and techniques to increase control. A scalable project methodology actually saves project managers time so they will comply with the process. That will produce better data you can use to allocate resources to the right projects. How Project Methodology Evolves

A scalable project management methodology can be tailored to meet the needs of each project; small, medium and large. That is the formula for solid control and success across the organization’s entire portfolio of projects. Let’s look at the three levels of our scalable project management methodology.

Project Management Methodology: Tier #1 Projects

The first level or tier of our scalable project management methodology covers about 60% of the projects in most organizations. There are  usually less that 10 team members and they, plus the project manager, all work in the same department or functional area. They report to the same boss who is the project sponsor. On these small projects, the scope statement and requirements shouldn’t be complicated. These elements make up the Broadbrush Plan. The project manager documents the business value the sponsor wants (the project scope) and the major constraints, like time and cost.  Most importantly, the Broadbrush Plan lets the project manager break down the project scope into assignments for the team members. These assignments include clear performance expectations. They allow the project manager and the team members to make accurate estimates of work and duration for the schedule.  They use the Broadbrush Plan and the estimates to develop a dynamic schedule based on the resources available.

Getting weekly status reports from the team members lets the project manager spot problems early when they can be fixed. They’ll be able to keep the project schedule updated in 10 minutes a week using project scheduling software.  The Tier #1 methodology meets the organization’s requirements for setting priorities and allocating resources. It does have limitations, however. As the scope of the projects and the size of the teams increase, the project manager must use the next tier in the project management methodology.

Project Management Methodology: Tier #2

Projects are a little larger in the second tier of our project management methodology. The team size usually ranges from 10 – 15 people and the project manager needs to borrow resources from different functional areas. Instead of a single sponsor, there are multiple sponsors/stakeholders the project manager must manage and satisfy. The project manager must use more sophisticated techniques to define the scope and  gather the requirements. He/she needs to focus on each business-relevant outcome and define network of achievements that lead to it.  That will let the project manager control scope creep. Lean Project Management

In addition to borrowing people from multiple departments, the project manager may be hiring contractors.  That makes the authority and management issues trickier. These projects involve more dollars and hours than Tier #1 so the project manager will use more elaborate estimating processes for work, duration and cost. The scheduling is more complex so they use the software’s optimization tools to ensure they’re using their resources efficiently and will finish as early as possible. The project manager also needs to develop high levels of team member commitment to the project’s time frames and deliverables.  Gaining that commitment is more difficult when the team members are borrowed from other areas and the project manager isn’t their “real” boss.  So they need to more actively manage the team culture.

Finally, Tier #2 projects have greater risk and higher stakes so the project manager needs to do risk management. They will probably limit their analysis to qualitative risk assessment which is an inexpensive technique.  They’ll focus their risk management on planning the risk responses and mitigation strategies to avoid the negative consequences.

Project Management Methodology: Tier #3 Project Management Methodology

When the PM manages large strategic initiatives or major projects for clients they need to add Tier #3-level techniques to their project management methodology. The project manager will align the project with the organization’s strategy and go through an extensive scope and requirements process. They will do a detailed cost-benefit analysis and feasibility studies.  Then the project manager will break down the scope into measurable/verifiable outcomes that they”ll use as the basis for estimating the work and making team member assignments. He or she must make sure everyone knows exactly what business result the project is targeting and what is explicitly excluded from the project. They must define success in measurable terms and measure progress at each stage in the project’s lifecycle. Additionally, their risk analysis includes quantitative risk assessment which is more elaborate and includes statistical assessment of the risk’s probability and impact.

The project team must have an organization structure.  The project manager needs assignment and reward authorities for contractors and team members who are borrowed from other departments.  To create a high-performance team culture, everyone needs a shared objective and commitment. This requires the use of psychological motivation and commitment techniques far beyond a slogan and t-shirts.

Summary: Project Management Methodology: Scaleable for Each Project 

There are significant benefits to using a 3-tiered project management methodology for projects as they increase in size and complexity. You can expand and contract it to fit the size of your projects – small, medium and large.  It is wise to start with a simple methodology that actually saves the project manager’s time.  That’s how you get compliance and improve your organization’s project performance.

We offer books and courses that teach the tools and techniques for each level of our 3-tiered project management methodology. You can also earn a certificate in project management. 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 courses in your specialty.

At the beginning, 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


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.