Glen B. Alleman was kind enough to respond to one of my recent posts, taking exception to my assertion that a simple, calculated estimate at completion (EAC) is probably the most powerful underused tool at the project manager's disposal.

He laid out a scenario where a varied time-phased budget (Budgeted Cost of Work Scheduled, or BCWS) would introduce a sufficient level of error into the calculated EAC so as to significantly reduce its effectiveness.

I must disagree, if, for no other reason, than the time-phased budget isn't part of the calculation.

As I discussed in that earlier post, the classic cost performance index divided into the budget at completion formula can be algebraically simplified to dividing cumulative actuals by the estimated percent complete. With those two data points, remarkably accurate management information can be gleaned and used to avoid project catastrophe.

To support my argument, I would like to ask: What other options are out there? What other methods can rival the simple earned value management (EVM) version?

After suffering through semesters and semesters of accounting, and semesters and semesters of finance, I can say with a fair degree of certainty that there's nothing in the accountant's toolbox that can even come close to the accuracy of the simple EVM method.

As counter-intuitive as this may sound, the person who has been through a 40-hour EVM class is in a far superior position to relay accurate at-completion project costs than is the accountant, who, of course, needed years and years of post-secondary education.

I intend to speak on this at the EVM World 2009 conference being put on by the PMI College of Performance Management this week. If you're in attendance, look me up. Otherwise, leave a comment. I'll see it, I promise.

I am just back from the PMI Global Congress 2009--EMEA in Amsterdam, Netherlands.

PMI seemed focused on the environment--with a keynote emphasizing the need to be more green--and on the value of project management, with the Research Working Session and a few tracks by PMI personnel on the subject.

The majority of tracks, however, seemed to hit on different topics, including:

1.    People issues, like decision-making, leadership, communication, culture, politics and stakeholder management
2.    The strategic link of projects, like organizational project management, project selection, portfolio and program management and the PMO
3.    Agile

I think this last one is a growing trend in project management.

Many of the concepts of Agile can be traced back to fast-track construction projects, where basic principles like co-location, fast prototyping, iterative development, daily orientation meetings and other concepts were developed.

In IT, the Agile methods evolved in the mid-1990s in reaction to what is called the "waterfall model," a sequential approach to programming.

In 2001, 17 prominent thinkers of what were then called "lightweight methods" issued the Agile Manifesto, which states four basic principles:

•    Individuals and interactions over processes and tools
•    Working software over comprehensive documentation
•    Customer collaboration over contract negotiation
•    Responding to change over following a plan

Although, in a way, Agile seems to be the antithesis of project management, as explained in A Guide to the Project Management Body of Knowledge (PMBOK® Guide), it can be very advantageous to use it in turbulent and strategic settings.

As project management is used more and more to manage strategic change and projects become more complex, Agile principles will influence more and more the management of projects, and more specifically, program management.

More in my next post ...

The Agile community has some good ideas to pass down to conventional project managers, including:

Customer Engagement
While it may not be possible to iterate the building of a piece of machinery, engaging and explaining to the customer in their language--no jargon--what's happening will highlight issues early. If the customer doesn't like something, the sooner you know, the better.

One of the key tenets of Agile is to engage effectively with your customer and end-users, understand their needs and problems, and then deliver an effective solution. This requires regular and effective communication, openness and accountability, and a good measure of trust to support robust relationships between the project team and their key stakeholders. It's a pity so many project managers put their energies into fighting the client rather than collaborating.

Going Light and Lean
Those are hardly new ideas, but they've been embraced by the Agile philosophy for a good reason: They work. Lean was developed by Toyota as a manufacturing philosophy and has been adapted to many other areas. Some of its key principles--such as minimizing unnecessary movement, simplifying process and continuous improvement--have huge potential in project management.

Light is focused on the minimizing unnecessary overhead. Complex plans and processes should be simplified, but only to remove excess complication, not to remove core requirements.  

Slimming down the project management overhead to its optimal level is probably the easiest way to free up the resources needed to engage your stakeholders more effectively and is definitely supported by the A Guide to the Project Management Body of Knowledge (PMBOK® Guide).

For more information, see Light Versus Lean -- Steps to Improve Project Efficiency from PMI's Community Post.

Amidst all the talk about the value of project management offices (PMOs), maybe organizations should be looking at size.
 
"PMOs do not have to be big", says Ardi Ghorashy, PMP, PgMP, a partner with 80/20 Consulting Inc., Markham, Ontario, Canada, told me in a recent interview.

"The biggest mistake I think that companies make is that they create a monster organization with a lot of overhead and they also bring all the project managers to report into a PMO. That creates a big lump sum of cost sink that becomes very visible at the executive level every year when you review your finances.

Then the question will always get asked, 'What's the return value on this investment.' And project management has traditionally been very difficult and notorious at quantifying its ROI.

... By its nature, a PMO has such an encompassing impact on the organization that it affects a lot of things. You can't really measure it very easily. .... These days we say PMOs need to be implemented extremely thinly. [Thin] PMOs will demonstrate the value very, very easily."  

What do you think? Are "thin" PMOs the way to go?

It's hard for me to predict the future. Although our team meets project deliveries, we normally range from -5 percent to +15 percent of the scheduled delivery date with one exception. We struggled on one project and finished past the promised delivery date by 50 percent of the project schedule.

We documented lessons learned much like what Dmitri Ivanenko has described in a previous post.

But I was not satisfied, so I surveyed my colleagues on how they thought we could better estimates next--and every--time.

Here is what they said:

•    Anticipate volatility and plan frequent feedback opportunities with customer. If every project you manage starts with a solid set of requirements that never changes, count yourself lucky. Most of the time, that's not the case. Be in the mindset that projects go through changes and have frequent feedback sessions with your customers to help minimize last-minute surprises.

•    Utilize both top-down and bottom-up approaches. Visions, objectives or problem statements provide the boundary of the project scope. Agree on top-level requirements and then work with the experts on coming up with quality estimates for the detailed tasks. Clarify any assumptions/questions during this time and use A Guide to the Project Management Body of Knowledge (PMBOK® Guide) processes and/or any parametric modeling tools to create the initial schedule.

•    Plan the high-risk item(s) early. How many times have you seen a schedule task showing 90 percent complete only to have it continued at 90 percent for a long, long time? Make sure the risky development work is scheduled up front. This practice gives you the greatest flexibility on mitigating risks you may not have planned for.

•    Assess your team's experience with the project effort. Understand how experienced the team is with the kind of problem you are asked to solve. And staff the project with the right people for the jobs even during planning stage. You may not need all of the positions filled, but you will need to have experienced experts to provide quality estimates.

A Guide to the Project Management Body of Knowledge (PMBOK® Guide)--Fourth Edition has nine technical knowledge areas plus the overall integration processes.

By aligning these processes to the Agile delivery methodology, effective project management will enhance the probability of success. But you must recognize the processes are applied differently.  

Some of the areas that need an Agile approach include:

Project Scope Management
Traditional project management expects scope management to define the output. The final outputs in an Agile project should be defined in terms of achieved capabilities--how the capability will be achieved will be discovered along the journey.

Change control will be more challenging, as is configuration management. The overall project needs a really good systems architect to keep each iteration or sprint focused on contributing to the big picture.

Project Time Management
In an Agile project, scheduling and workflow become closely aligned. The overall system architecture optimizes the sequence modules needed to be built in to allow progressive testing and implementation of capability.

This defines the schedule. Scheduling should be at a much higher level; each sprint is likely to be a single activity of one to two weeks' duration.

Project Cost Management
Agile projects should be based on either a cost-reimbursable system, or the client accepts scope is a variable based on achieving the maximum improvement possible for a pre-set budget. This is a totally different philosophy to traditional project governance.

Project Quality Management
This is probably easier under Agile. Quality is continually assessed by the involvement of the client and the iterative release of modules to production.

Project Communications Management
The level of trust needed to run an Agile project is much higher than a traditional project. Effective communications in all directions are essential.

Project Procurement Management
Agile works in a collaborative partnering space. In the engineering world these are called alliance contracts. Traditional contracts do not support Agile delivery methods very effectively.

More later....

A lot of energy has been spent investigating the "value" of project management. My question is: value to whom? Doesn't it all boil down to what the projects' decision-makers do with their project management information?

Imagine a project manager who pays a very small amount for a very advanced cost and schedule control system, and the system reliably produces accurate information in a timely manner. If that project manager ignores that output, and instead acts out of impulse, then the value of the project management information system is zero.

And, to be blunt, no amount of eat-your-peas hectoring from our side of the debate will lead such a project manager to have an epiphany and turn away from his or her nefarious ways. Conversely, a project manager who pays a great deal for a system that barely reports projected costs at completion and forecasts completion dates, but uses that information to avoid a massive overrun or delay, has an extremely valuable system.

Not to abrogate the debate, but, in my opinion, the value of project management is like the macro-economists say: It's what somebody's willing to pay for it.

When I started in project management many years ago the only measures we had for success were cost, time and quality--the famous (or infamous) triple constraint. Nobody was talking about scope or earned value.

Many variations of this triangle exist and today its basic concept is getting more and more muddled.

In the early 1990s, the concept of scope started to become more and more important and was seen as the area of the triangle, again varying against cost, time and quality. And value was still very much focused on quality. Good value was when the highest quality was achieved for the least expenditure of resources.

Today, stakeholder satisfaction, which can include quality, but also scope and other issues have replaced the concept of quality.

In project management, value could be represented as scope and quality (satisfaction) on one side of the scale and cost and time (resources) on the other side: the more scope and quality for the least cost and time yielding the most value.

Although this is an interesting concept, it is usually not the project manager's role to define these elements. They are usually imposed as parameters in the project charter.

It is the role of the sponsor to define the value that the project will generate by setting the scope and quality that will satisfy the stakeholders and define the cost and time that will be acceptable and achievable.

There is a simple equation that can be represented graphically to represent this:

If offered benefits are greater or equal than expected benefits, satisfaction is achieved. If available resources are greater or equal than required resources, value can be realized.

Typically projects are measured against their capability to fulfill strategic objectives and business benefits, including increased operational capabilities.

Estimated resources (time, cost and human resources) are measured against resources available at the time the project is scheduled to take place. If both ratios are positive, then value will be achieved. If many projects are competing against each other, those that provide the highest benefits to resource ratio will be chosen.

But is this truly the norm? Is this how things work at your organization?

No one knows project management better than you, the practitioners in the trenches. For months, you've been weighing in on the blog.

Well, here's your chance to have your voice heard in PM Network.

Every month, the magazine will run a Voices on Project Management column. Project managers will share ideas, experiences and opinions on everything from trends to new methods of doing things.

If you're interested in contributing, please e-mail us your idea.

Check out the debut column by Peter Taylor, PMP, weighing in on the pressure for PMOs to perform in tough economic times.

My company is currently in the midst of delivering software that will help revamp our enterprise measurement program. In a way, we are defining the standard to which our software development projects will be graded on.

Here are some of the measurements we are interested in:

Product fault density
Requirements volatility
Defect containment
Development productivity
Hours per defect
Software size growth
Engineering percent rework
Action item aging
Risk and opportunity tracking
Earned value management systems measurements such as cost performance indicator and schedule performance indicator

The benefit of having a set of common measures for our business is quality product deliveries--which translates into increased customer satisfaction and ultimately improves the bottom line.  

Take for example the measure of fault density. This is a lagging indicator to measure the quality of the software product after the development effort has completed. This is measured in terms of 1,000 logical source lines of code (KSLOC). This measure is calculated as:

        Number of Defects/ KSLOC

The data are compared against organizational thresholds. Root cause analysis on the variance can point to issues with software complexity and insufficient/ineffective test life cycle. Keep in mind that having meaningful thresholds calibrated for your organization is the key to ensure you don't waste your time with needless analysis.

With that said, what measures do you consider important to your business?

How many times has this happened on your team? An engineer switches off his machine on a Friday evening, enjoys his weekend, only to come back on Monday to find out the computer won't start or connect to the network. It's a very common problem--and for teams like mine that are close to 50 people--it occurs nearly once a month.

It takes the IT team a day to get everything working again, which may push back an already delayed schedule. How do you prepare the mitigation/contingency plan for this kind of risk? It may seem minor, but how many of us even identify these types of little things as risks? We should.
 
In this instance, I suggest the project manager keep a backup machine with the required software and hardware ready for the team. I know it will cost more money, but if you are able to save a day's effort every month then it would be justifiable.

How do you prepare for these seemingly "little risks"?

See the article, Plan for Everyday Risks, Brace for the Ordinary, by Carl Pritchard, PMI-RMP, PMP, published in April in PMI Community Post.

This is a continuation of the post Creating Trust in Agile.

Agile advocates (AAs) need to understand their key stakeholders and empathize with their perceptions, fears and requirements. Yet far too many technical managers see this as unnecessary hard work--and then they wonder why their projects end up unsuccessful.
 
Forget the jargon of "sprints" and "iterations." Communicate in your stakeholder's language. As an Agile project is progressing through its cycles, what benefits are being delivered and how can they be measured? What contingencies are in place? What real progress is being made from the business perspective?

Mind you, this is probably good advice for 90 percent of IT and technical projects. The challenge facing AAs is they don't have detailed plans and traditions specifications to benchmark progress against. New ideas need to be developed.
 
AAs should also create ways of managing and reporting risk, scope, cost, time and quality--not from the technical in-team perspective but from a senior management perspective.

The essence of Agile is flexibility and change. The traditional way of dealing with these issues is by measuring the current variance from a predetermined baseline. The issues are no less important in Agile. They just have to be managed and reported differently. The challenge for AAs is developing effective ways of communicating how they are being managed to their senior management.
 
Finally, AAs need to have ways of differentiating problems suitable for Agile solutions from those that need a different approach. Agile is not a cure-all for every project and problem--senior management knows this and AAs need to focus on areas where real value is created by the methodology.
 
I'm not an AA. So I'll leave it up to the Agile community leaders to work out a solution ...

Over to you for comment!