There has been much discussion of late regarding “agile” project management in places other than project management forums. The Agile Modeling forum on Topica has broached the subject of “what is the role of a project manager on an agile development team?” This is not only a good question it is timely as well. Hal Macomber’s BLOG presents topics of “lean construction,” other sources are starting to discuss the role of agile thinking in all aspects of management and development. Quoting from these sources and BLOG’s is probably poor form, but I’ve started a link to collect them for my own reference.
Estimate to Complete versus Estimate at Completion
My next discovery in the New Year was to realize that many project managers – some of which work for me – confuse the importance of an “estimate to complete” (ETC) with an “estimate at completion.” (EAC) This is not to say they are confused about the term, its definition or any of the semantics associated with these two metrics. The confusion comes from not including all the sunk costs in the assessment of the project at the point in time of the analysis.
When asked in a project review meeting “what’s this project going to cost in the end,” the natural response is to tell us the ETC. I say this is natural because they seem to be looking forward to how much work is left on the project. This is a “natural” view since all the work in the past is just that – in the past. Why would we be interested in data that has passed under the bridge? We can’t bring that sunk cost back; we can’t recover from the mistakes of the past. Or can we? If we use EAC, then the sunk costs of the past become useful as a predictor of the to-be-sunk costs of the future.
By including the past sunk costs – with the appropriate assessment – an improved vision of the future can be produced. What was the economic efficiency of each dollar invested in the past? Did it produce a dollar of value for the project? This is the way to look at earned value – for every dollar I invest (ACWP) in this project how much value (BCWP) is returned. If it is not 1 for 1 or greater, then working harder (spending more money) will not improve the schedule. Only by working more efficiently – improving BCWP for every ACWP investment – can I ever make up schedule. Without this knowledge the ETC is a “fantasy” number. It tells you almost nothing with confidence about the future performance of the project.
Our new understanding means that project assessment must include all the past efficiencies in terms of money (ACWP) and resource productivity if I’m ever to get a straight answer to the question – “how much will this project cost in the end?” “The past is a predictor of the future,” should be tattooed on each project manager – OK washable tattoos.
The third discovery is a change in terminology for our project management methods. In our little IT shop we use Extreme Programming for some projects. Others are pure waterfall. While still others are “herding cats” inspired. The term XP-inspired has entered our vocabulary. When we attend the local XP Group’s meetings and listen to others describe their XP processes, we wince at our feeble contributions to the discipline. We changed the words now and use XP-inspired to describe our processes. Some pair programming; lots of Unit Tests; some story cards, but also formal documents; lots of code standards, configuration management; and some attempts at code sharing. In the end we’ve made a reasonable attempt to do XP in the spirit of XP.
What’s next in 2004?
What’s next? My personal mission is to define in clear and concise terms the concept of “making decisions in the presence of uncertainty.” Why you may ask? Well the answer is – it’s not been done. Oh there are gobs of papers and books on this subject. Some critically important ones: Making Hard Decisions: An Introduction to Decision Analysis and Making Multiple–Objective Decisions, are two handy ones on my bookshelf. Steve Devaux’s Total Project Management is another book with chapters on decision making.
The problem is they’re not specifically targeted to the problem I have at the moment, which goes like this:
We have a fixed budget handed to us by our customer, who in turn is working on a fixed budget as well. We have to provide IT services to this customer within well defined parameters – fixed minimum requirements. This is common in most IT shops. But our challenge is that we have to withdraw our services over time since we’re closing our site. This closure is a good thing, since that’s what we do for money. Our site is a former nuclear weapons plant that is being decommissioned and cleaned up. So our job is to “go out of business.” What is missing from our analysis tools is the ability to make decisions on probabilistic events in the future and unknown (but knowable) benefits to the customer.
The tool set we landed on is “real options.” Expected Monetary Value (EMV) is one approach, plain old ROI, IRR, NPV, Economic Value Added are others. But none of these answers the question – when is the right time (and what is the associated cost) for “stopping” this project? By stopping we mean investing no more, pulling the plug on the investment (or recurring cost) and “booking” the benefit at that point. This is an “options theory” problem. This is the decision to “exercise” the option either to buy or sell.
So what’s next is to start down the path by digesting all the “real options” materials I can and formulating a simple (meaning spread sheet) approach to answering the question – “when is enough, enough?”
As mentioned last month, I’m expanding my role beyond the PMO and into business development and larger business management. While traveling in January to some of the scenic spots with the DOE complex – yea right – I’ve gone through the current PMBOK 2004 Draft. There are many new and interesting changes to PMBOK 2004, not the least of which is the removal of the antiquated spiral diagram as an example of how to manage a software development project. Remember this is a column about agile project management. Also there are better diagrams showing the various process areas and how they are related.
PMBOK 2004 and the Voice of the Customer
One “killer” mistake though is evident in a data flow diagram, Figure 3.3, that shows the five major process groups, the data exchanged between them, and the external contributors to the data flow. The “customer” is involved in two, count them two, locations. At the beginning the processes flow through a Statement of Work or Contract and at the end through a Final Product, Service, or Result. No where in the data flow and the work processes does the customer get involved. Oh sure there are the required change requests, project plan approval cycles, policies and procedures, and other artifacts of project management processes.
But the “voice of the customer” is only heard in the beginning and at the end. Is this the 21st century management process model that will guide the profession of project management? I certainly hope not. One only needs to look as far as any Design for Six Sigma book for guidance. I know the PMBOK is a “body of knowledge” about managing projects. That it’s not a procedure or policy book, or a guide for actually managing projects. But inside its covers are “process diagrams,” “data flow diagrams,” and “execution diagrams,” for managing projects. Pictures of how to actually do the work of managing projects. The interfaces between these process groups, the activities performed inside each group, and the artifacts left behind from these processes, rarely have the customer’s finger prints on them.
The Role of a Program Management Office
I work in a Department of Energy weapons complex closure environment. Our goal is to “go out of business” in late 2005. As a manager with departments delivering project and program management, software QA/CM/IV&V and system development, our “motivations” are conflicted in ways we’ve never considered. The Program Management Office (one of my departments) is now involved in defining how we’ll go out of business – Program Termination Plan is the PC term.
One question in the current budgeting process is “what is the role of a Program Management Office?” In a growth environment this is an interesting question. In our declining returns environment its even more interesting, since now everyone has to answer “what have you done for me lately.” I’ve been asked the question – and rightly so – what value does the PMO provide to site closure?
Here’s my answer and I’m sticking to it.
We have about 200 projects that are managed through a variety of means. Some directly funded by customers, some directly identified in our baseline, and others called “level of effort,” also funded from the IT baseline. Our baseline funding is defined at the beginning of the fiscal year, like all government contracts. Our project funding is as well, but the project owners have more flexibility to move money around. Our scope of work is defined in a contract as well as specifically by our customers and the regulatory environment.
One question the PMO answers everyday is “how are we doing against budget?” This answer comes from our internal cost accounting systems. In the typical Byzantine way these numbers are rolled up into an earned value report we provide to senior management on a monthly basis. Now you may ask who cares about these numbers? Well we care, because our funding is “fixed.” We over spend during FY 04, and we have to stop work, send people home, shut down our services. So knowing at all times our Estimate At Completion (EAC) is a critical success factor. Doing it for 200 projects is not a “side job” for an individual project manager. It takes a department to deliver this.
The real value though is the determination of our capacity to perform work. Given our fixed budget, fixed scope of work, what is our ability to deliver value to our customers on a daily basis? A bigger question of course is – what “IS” the value we deliver on a daily basis and how can that be dollarized.
A Topic for Next Month
This brings me to a “big question” that never ceases to amaze me in the IT business. “What is the value of an application or a service?” There are ROI answers for that question. But from a service management point of view these are not very useful.
So here’s the ground work for next time. The “V” in Earned Value is the cost component of the project. The “I” in ROI is the investment required to deliver that project. The “R” of course is the return from that investment whose budget is reflected in BCWS of earned value.
A simple minded approach is to compute “R” from “I” or “V” and find the break even point. Not what happens in IT to service operations, cyber security, desk top support, network operations, are even the PMO? How do I compute “V?”
"The Herding Cats monthly column is designed to stimulate exchange of observations on project management topics. To promote such exchange a Weblog called " Herding Cats Letters " is available where your comments may be posted and I can directly respond. The purpose of the weblog is to capture conversations. As in any agile process, thoughts evolve and revisiting past issues in light of new information will be valuable to the community"... Glen Alleman