mombo

Reflections on Project management

Is agility becoming Kosher?

I'm happy to see more and more signs that the agile methodologies are getting more and more accepted in the IT industry these days. Clearly the enormous popularity of SCRUM helps a great deal in spreading the message of agile thinking.

I'm looking for new opportunities these days, and it's clear that my knowledge of SCRUM is a plus for me at job interviews.

Now even the project management portal Gantthead (who's name ironically stands for everything non-agile) is adressing "agile magic" in their latest newsletter.

But hey - I don't blame them. The agile methodologies works in the real, imperfect world!

posted by: mombodk at 09:07 | link | comments |

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 09: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 21: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 09: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 07:29 | link | comments |
team estimates commitment, estimation