mombo

Reflections on Project management

Earned Value is crap

Looking for new ways to improve how I follow up on progress in my projects, I've been searching for tools to help me. As you all probably know, the Earned Value method is a way of analyzing project progress from financial data. I've been trying to put it into practical use for some time now, and let me tell you my conclusion: Earned Value is crap. Useless. Now I've said it. It is of no value at all. Period.

All I want to know is if we're on track. Simple question, but no simple answer from Earned Value.

Earned Value advices me that there is something called "Budgeted Cost of Work Performed" and "Actual Cost of Work Performed". BCWP is the sum of the estimates of the activities, that we performed. Not the work we planned to perform, but the stuff we actually did perform.

ACWP is the sum of the cost of the stuff we actually did. Earned Value advices me to calculate BCWP/ACWP. That's called the CPI. Cost Performance Indicator. Not too bad. Just math. But the problem is, that it just tells me the relation between the money we planned to spend and the money we've actually spent. It only tells me if we're spending more or less than what we expected to. If we're spending more money than expected to, it may be because our estimates were wrong, or because we're working on more stuff than we expected to. Does that tell me if we're on track? Of course not. Useless.

Next Earned Value advices me to calculate the SPI, which is BCWP/BCWS. So is that the silver bullet? Well, we already know BCWP. BCWS is "Budgeted Cost of Work Scheduled". So the SPI is the sum of the money we thought we would spend on the stuff we've finished, related to the sum of the money we thought we would spend on the stuff we thought we would have finished by now. Confused? Yeah, me too. And all I wanted to know is if we're on track.

There are many more exciting acronyms and funny formulas, but there seem to be some serious limitations to the method. Consider for example, the case where a project proceeds in stages, with tasks and people changing between stages. The CPI may be very bad for stage 1, but what does that tell about the coming stage 2? Absolutely nothing. Since the tasks and people changed, you can't just conclude that the current CPI is an indication of the future. For Earned Value to make a little sense, you need similar tasks that proceed over a long time with a certain amount of volume. For example 2000 hours of coding activities. But even in that case, if you break down the tasks, you'll probably realize that the tasks that are performed in the beginning are very different from the ones that are done in the end, so you really can't use the statistics gathered in the beginning to predict what will happen in the end. Crap!

Additionally, how on earth should I manage to explain what BWCS, ACWP, EAC, CPI means to those I report the project progress to? There are more acronyms involved here than in the average Network Infrastructure Tutorial, and they are just looking for the simple answer.

But admittedly maybe it's not all crap. CPI does tell us, if we got the costing and activities right from the start. That is, on the work we have performed, did our estimates turn correct. SPI does tell us, if we're putting as much effort into the project, as we expected to. But there is much more to a project status than just SPI and CPI, and I must look elsewhere for the answer. Next up on this blog: Where to look for the project status.

Learn more: en.wikipedia.org/wiki/Earned_value_management

posted by: mombodk at 11:39 | link | comments |

Four vertices on the Project Triangle?

The Project Triangle is widely known here in Denmark. Is it likewise in the rest of the world?

I've heard various suggestions on additional vertices for it, like quality or ressources. Now I'm going to have a go at a suggestion myself.

As I understand the Project Triangle, these are the three top level factors that sums up the project: The goals of the project (features), the time it takes to complete, and the money it costs. The notion is, that you can't change one of them without it affecting the others: If you remove features, the cost and schedule will deminish. If you move the deadline ahead, you will have to do something about the cost and/or features.

From my experience goals, cost and time not only changes when you decide to change them. These buggers tend to change by themselves during the project. Costs have been seen to increases although no new features are added. New tasks seem to surface, although no new features are added. The Project Triangle does not account for such behaviour, although we see it all the time. So what's missing from the equation?

Well what if you're a software development team, developing a new fancy website in Visual Studio 2005. Suddenly management decides that all projects should upgrade to Visual Studio 2007. Stuff like that happens all the time in the real world. Surely that upgrade is going to affect the cost and time in some way. What if 3 great developers find new jobs during the project. That is going to cost time and money for training, not speaking of the likely challenge of even finding replacements. What if we just plainly got the estimates wrong. The cost of the project changes, but nothing new is added.

To encompass all these different factors, I'm proposing a fourth vertex called "premises". Eg. a premise could be Visual Studio 2005. If that premise fails - you are required to upgrade and continue on Visual Studio 2007 - the time and cost vertices are going to increase in size. Unless of course, you counter the extra cost by reducing the features, so you can still make it to the deadline and within the cost? Maybe a good question of the Project Board? I think the fourth vertex could be really helpful in communicating, how the three other vertices of the Project Triangle are dependent on the premises that we identify or assume, when we layout the project.

 

posted by: mombodk at 23:16 | link | comments |

Identifying a delay

In my previous post, I claimed the existence of the chicken game. The question remains: in a world of chicken games, how can the client identify a delay on the IT supplier's side as early as possible. I think there are 2 basic strategies: probing for information on project progress , or have the product delivered in steps.

Probing for information

Arguably the easiest thing to do is just expecting the project manager to tell you. I must admit that I no longer believe that the suppliers always act in the best interest of the clients. Additionally, I no longer assume the professionalism of the Project Managers I work with. So the risk is he doesn't tell you or he actually doesn't know himself. I think it's worth thinking about under which circumstances it's reasonable to expect a Project Manager to inform about delay. If the Project Manager risks her butt, or if she knows that the delay is immediately brought to the project board, the Project Manager will be highly motivated to conceal the delay, hoping to be able to get on top of things again. Without giving the PM the impressions that deadlines doesn't matter at all, how do you convey to him or her that you would rather know about a delay asap, and deal with it, than be the last to know?

In theory the true state of the project can be verified by following up on the actual work results on the supplier's side. But the level of detail you need to go into is horrible, and likely you won't be allowed access to the information you need. Additionally you need to be able to interpret what you find. Obviously you end up doing the supplier's Project Manager's work.

Another way to probe for information is to get under the skin of a few of the team members on the supplier's team. Like anyone else they probably won't care to hide important facts from a good friend. Until now I've never intentionally built relations with team members just for the purpose of learning about the true state of project, but never the less I have on multiple occasions learned important facts about the projects just because I "had a beer" with a guy or girl. Just remember to pay back the favor. After all projects requires a high level of decency.

Ask for step by step deliveries of actually usable results

Revealing myself as pro agile methods yet again, there is a much more straight forward way of knowing about the true state of the project. If you ask the supplier for a methodology that results in a product delivered in steps, you can easily monitor the actual project progress. If you get a new delivery of usable functionality each month, the level of product completeness is simply a function of how many of your requirements are met but the most recent delivery. There will be no hiding behind lengthy periods of analysis or design writing, nor long periods of basement coding without intermediate results surfacing for a little sunlight and your review.

posted by: mombodk at 11:48 | link | comments |
plan, delays, project management

Estimation best practices from Mike Griffiths

I did a posting on estimation a while back, and I have a follow up coming. Meanwhile Mike Griffiths did a posting on best practices a while back. It's definately a good read.

posted by: mombodk at 09:29 | link | comments |
team estimates commitment, estimation

The Chicken Game

On the topic of "Delays", here's the story of what we called "The Chicken Game". Let's say that I once knew a Project Manager who worked in the IT department of a larger company. The department developed and maintained a substantial amount of homegrown systems. The clients were the different business units of the company, those that actually sold products and made money from the customers. It is fair to say that though they were all a part of the same company, projects ordered by the business units were nearly by contract. So if the IT department promised a delivery by a given deadline, it would be put in the contract. If the deadline was not met, management on the business side would complain to mangement on the IT side, and everybody would be very unhappy about it. If the project was important, the CEO would know and be very unhappy too. So for the project manager in IT, there really wasn't much difference between dealing with a "real" customer and the business units.

Some systems were outsourced to a subcontractor. When a project required changes to an outsourced system, the IT department would initiate a subproject with the subcontractor to handle the changes. The IT department was the customer's single point of contact, so the subproject was entirely the responsibility of the IT project manager.

To wrap it up: IT was making code changes to an inhouse system, and the subcontractor was making code changes to the outsourced system, on which the inhouse system depended. Obviously they depended on each other to make it to the different deadlines for design, code, testing, release and so on.

Now, surprisingly (sarcasm, ed.) sometimes stuff would not complete by the deadline. Since IT and the subcontractor was in fact working closely together, and it was pretty easy to look over each others shoulders, it was easy for the developers to spot a delay early. If, for example, the subcontractor had not begun to ask for interface specifications or test data, chances were that the subcontractor wasn't very far. So if the test deadline was just around the corner, the subcontractor probably wouldn't make it.

But sometimes the IT department was behind schedule too. No one was eager to take responsibility for a delay, and if it was obvious that the other side was behind schedule as well, it would be beneficial to just wait for the other party to admit their delay first. That way, you could just hide that you were behind as well. And while things were sorted out, you could finish your work. Now, when both parties had the same thought, the Chicken Game begun. Both IT and the subcontractor knew they were behind. No one would admit it first. Of course eventually the delay would be revealed, but often very close to the deadline.

Unfortunately the sooner a delay is identified, the easier it is to handle. So though "The Chicken Game" sounds fun, it really was a losers game for the customer.

posted by: mombodk at 16:03 | link | comments |