Project management methodology

Having a project management methodology to follow is a cornerstone of consistent project success for individual project managers and their organizations. A methodology allows us to avoid reinventing the wheel every time we start a project and it allows organizational level control of project priorities and resource allocation because all projects are consistently planned. Unfortunately there aren't many fully developed methodologies available. The Project-Management Body of Knowledge, published by the Project Management Institute, is not a methodology it's a vast encyclopedia of the best practices in project. In fact, the PMBOK makes repeated reference to organization having their own project management methodologies without providing any.

Our Achievement Driven Project Methodology (AdPM) is unique in a couple of ways. First, it's scalable and gives project managers guidance as to "how much" project-management they should do on different size projects. The methodology can be scaled down for small "puppy projects" where the whole plan is a few lines long. It can be scaled up for hugh "pachyderm" projects and several steps in between. Second, the methodology at all scales maintains its focus on accountability for measured results and the measurement of business value. Third AdPM keeps paper work to a minimum through the use of our templates and dynamic project scheduling techniques.

That focus on measured performance & metrics provides great support for the individual project manager making assignments. It gives team members a crystal clear understanding of the performance that's expected of them. Finally, it gives executives responsible for managing a portfolio of projects a powerful tool for measuring progress accurately in solving problems early.

To learn more about AdPM, watch the video on the five-step ADPM method for small projects.

We also have a video on organizational implementation of ADPM methods

Add you comments about project methodologies.

Best regards,

Dick Billows, PMP, GCA

Work Breakdown Structure

This week's video is about the work breakdown structure and the debate about how much detail we need to include. Is the WBS just a big to-do list? Or, is the WBS a list of verifiable business outcomes that we decompose from the scope definition which is also a verifiable business outcome.

There are lots of people walking around who favor the to-do list approach. The idea is that if somehow we can manage to list everything everybody should do, we'll have a successful project. This approach leads to monstrous work breakdown structures. They don't require much thought to assemble and they are quickly irrelevant but they make a very impressive thump, when we toss them on to an executive's desk. These monster WBS are also very difficult or impossible to maintain because at this micro level of detail many many things change each week. Most project managers don't spend the time to keep the to-do list current and so three weeks into the project the schedule and plan are largely irrelevant.

The decomposition approach which is a core technique in our achievement driven project management methodology (ADPM™) takes a lot more thinking. The sponsor and the project manager need to actually decide what outcome they want from each assignment in the project. This goes hand-in-hand with the philosophy of holding people accountable for their end results rather than micromanaging. The resulting ADPM work breakdown structures are much smaller, much easier to maintain and give us unambiguous checkpoints for project tracking.

Add your comments about this critically important project management issue.

Regards,

Dick Billows, PMP, GCA

Work Breakdown Structure(WBS)

When we look at failed projects, they almost always show the same flaw; a "to do" list work breakdown structure. Too many people think the WBS should be a listing of everything that has to be done in the project. That's the wrong way.

The right approach to the WBS is that we are designing assignments for our project team. That is, the WBS is a listing of the "hunks" of the project we will manage, not a procedure for doing the project.

What's you approach?

Dick Billows, PMP

Operation Rescue: Saving A Failing Project

But when we go in to rescue a failing project, the techniques are little different than starting with a clean slate. In my mind a couple of issues are critical:

First, the most important way to increase your odds of success in the rescue is to get senior management agreement's that the scope of the project must be re-examined and almost certainly changed. You need this authority because failing projects have scope problems. The easiest way to free up resources, restore focus on the business value the project should deliver is to slice away the blubber surrounding the core business value. So you start by going through the scope planning process all over again. This is not popular as it unearth's problems and that's why you get authority to spend your first week or so cleaning up the scope until you have a crystal clear and measurable definition of the business value the project should deliver.

Second, with the scope defined with clarity you can start to carve away the blubber that almost always surrounds it. It's not that projects are filled with bad ideas. It's that they're burdened with good ideas that are not necessary for delivering the scope. Once we clean away the blubber we suddenly have resources we can reassign critical path tasks and maybe gain some improvement in duration.

That's always our starting point. What ideas do you folks have to contribute?

Dick billows PMP, GCa

President 4PM.com

Does the PM have to be a technical expert?

One of our bloggers asked about the level of technical expertise required of project managers.

10 years ago, most organizations felt their project managers had to be the most expert member of the project team. The PMs were the technical gurus and the theory was they would have influence to direct the team due to their technical mastery. This didn't work too well when the team was bigger than 2-3 or when they involved people from non-technical areas who thought the guru was a geek.

This thinking provided a nice career path for subject matter experts but far too often the technical experts wanted to do the technical work of the project. This was just fine on very small projects with one to three people. However, as the size of the project team increased the technical guru had to move into the people management business and deal with other functional areas. Very often the gurus were not too good at cross-functional stuff and did not want to manage people in the first place.

Today, many organizations have suffered through the mis-management and failed projects led by technical gurus. They recognize that project management is a separate set of skills and that a project manager can control a team made up of people who are more technically expert in their disciplines than the PM.

So I'm a strong advocate of having PMs who are expert in managing projects and don't feel they need to know more than everybody on the project team.

Regards,
Dick Billows, PMP
President 4pm.com

The slippery slope

I had an interesting conversation this past week with a new project manager who works for one of our project office clients. Our staff was reviewing newly submitted project plans and found one that was extraordinarily detailed (it may be a new record for micro-management). I called the PM and asked why her work breakdown had so many tasks of such short duration; some as small as one and two hours in durations.

She said, "My boss wants no mistakes on this project and really tight control."

I asked, "But will your team members be submitting twice daily status reports?"

She laughed and said,. "That would be ridiculous; it'll be hard enough getting weekly status information on all these tasks."

I agreed and said, "Then don't you think you're going just a touch too far to have one and two hour tasks that we'll never actually track while they were in-process."

"I guess that's right. But how will people know what to do?," The new PM asked.

What's the answer to her question? Can we save her from micro-management?

Is it just the PMs who determine project success?

A lot of organizations kid themselves that project success or failure rests solely in the hands of the project managers. In reality organizations that do projects consistently well have a high level of competency at several levels.

First, executives know how to initiate projects and set a clear strategic framework within which project managers and team members operate. Lack of this framework is the major source of scope creep and it comes from executives who don't know how to play their role.

Second, senior management needs to set priorities and allocate people's time based on those priorities. When there are no priorities or allocation of resources we have chaos and 70 and 80% project failure rates.

Third, subject matter experts and managers need to know how to develop requirements, not in terms of wish lists but in terms of the business value that is needed.

Only when this foundation is in place can project managers and team members achieve consistent project success. Does your organization have all these pieces?

Project Estimating

Can a project manager refuse to make an estimate of when a project will finish?

Well it's reasonable to say. "I can't tell you when I'll finish until I understand exactly what you want.

But some sponsors want a completion date committment before the scope is clear. How should we handle them?

Project Management Office: Friend or Foe

In some organizations, the project management office turns out more rules, regulations and forms than the IRS. The anal retentive, nit pickers in the Project Management Office want to correct all project work, challenge every assumption and risk but be responsible for nothing. What is often the result is the PMO drives projects underground. Efforts that would normally be called Projects are now renamed and called; task forces, study groups, committees or water cooler meetings in a desperate attempt to avoid the bureaucracy of the Project Management Office.

In other organizations, the project office teaches a lean, scalable methodology that everyone can use. It gathers data is data, resolves resource conflicts and gives top management a high level view of the state and status of all projects. This is a far more valuable project office but also a difficult one to implement, as we need to fight off the "Big Brother" mentality that often surrounds the PMO.

What kind of project office do you have and how does it work

The Project Office; Control not Paperwork

Some Project Management Offices (PMOs) have bad reputations, often when they are run by nit-picking micro-managers who setup paper work jungles that do little but slow projects down. The result in those organizations is that people are still overloaded and have to cope with conflicting project priorities.

But a project office doesn't have to be like that. We worked with a couple of clients over the last ten days to set up Project Office functions... No departments or even full time people...Just systems and processes for control and reporting. We used our achievement-driven Project Methodology (AdPM) and these PMOs are achieving two big benefits:

• By requiring people initiating a project to committee to delivering a measurable business value from the project (the Measure of Success or MOS in AdPM). A lot of pointless projects are being killed before they can waste any resources.
• Projects are now prioritized and work loads are managed so everyone knows what to work on first

Best of all there is no new paper work, everything gets done in AdPM digital templates.

Here are a few more ideas on project offices

Best Regards,

Dick Billows PMP, GCA
President 4PM.com

Getting started fast on projects

In lots of organizations, starting fast on projects is a disease. They talk about being dynamic, aggressive and fast to market. What they're really doing is turning loose a project teams that starts work on the first few tasks with very little idea of where they are headed or how they will get there. No wonder that 80% of these projects fail. Anybody else see this going on?

Best Regards,

Dick Billows PMP, GCA
4PM.com

Managing with just due dates

Lots of project managers complain about executives who pluck due dates from the sky with no consideration for:

• the work to be done,
• the availability of the team or
• the other projects that are underway.

That kind of due date setting leads to high failure rates but the project managers are also to blame because they give executives only one corner or dimension of the project to quantitatively manage.

These PMs don't quantify the scope, risk or budget so the executive only has one dimension to manage that has hard-edged data. Read the article about Project having 4-Corners and cure your executives of the dates only disease.

Best Regards,

Dick Billows PMP, GCA
4PM.com

Estimating Project Duration

A PM asks. "Why should I spend a lot of time working with the team on estimates when the sponsor always cuts the estimates anyway?"

There are several ways to handle that situation. That kind of sponsor decision-making always goes along with high project failure rates. Project teams may slap together some piece of crap by the deadline the executive set. But then they spend 6 months cleaning up the crap. I promise you the executive is sick of failure too. The exec may even be more worried about the failures then you are.

In that very typical situation, it can be effective to tell the executive something like, "We're getting nowhere setting these impossible due dates that have no basis in fact. The team has no commitment to them and knows they are impossible. So on every project, the whole team knows we are going to fail before we start. Let's try managing a project with realistic dates that we can hit."

Anybody have other ideas on handling this situation?

Are all project managers like this?

A professional engineer who works on projects full time wrote in and asked:

I haven't been working on project very long but every project manager I have worked for is a clown. Here's what they do. They call you in and tell you how important the new project is and how the big bosses are "really watching this project."

I guess they think that I'll be really impressed by this talk about the importance of the project. I was the first time, but not since.

Then they tell you when your task has to be done, usually even before they tell you what you have to do. Next the describe all the bad things that will happen to you if you're late.

Then they explain what you have to do. But its vague with no specifics on the deliverables so you know they'll change it every week.

Are all Project managers like this?

Best Regards,

Dick Billows PMP, GCA
4PM.com