Archive for the ‘Project Management’ Category

Less formal, more rigorous

March 11, 2007

In conversation with our head of audit, I was explaining how our agile methodology is actually a lot more rigorous than old-school project management. We are also less formal. The two are hard to distinguish at first. Let me give a couple of examples.

We are more rigorous. If we start to move our timeboxes around, our whole paradigm falls apart. If we unexpectedly discover that a feature is going to take too long to test, we push it to the next iteration instead of moving the iteration end date out. If we don’t do this, we need to re-write the release plan, re-estimate tasks, re-do resource plans and (where I work at least) replan priorities for other projects, as well as generating the same set of documentation for these other projects. This is all waste work: work that does not bring us closer to client-valued features deployed and working in production. It’s also typically the thin end of the wedge: pretty soon our teams spend more time on documentation that on getting value-adding software working flawlessly in production.

We are less formal because all documents that we use are supportive not directive. I don’t demand people use a certain Excel template for a release plan. Thinking about certain attributes for each feature and for each iteration add value in our experience, and in teams that are starting up I strongly recommend (and yes, even enforce) this. But I don’t really care how our teams record this information. I have been down the path of only checking that everyone is using the same Word template or Excel sheet and mistaking that for real value — and I won’t be going down that path again.

Technorati Tags: , , , , ,

Is Earned Value Management valuable?

January 26, 2007

Eric Brown talks about Earned Value Management. I know that this is a respected practice recommended by the PMBOK amongst others. I have had more than my fair share of disagreements about the need to implement EVM.

I have one fundamental problem with EVM: it takes too long to track this information. I find that for the vast majority of projects that I or one of my PMs run, the team ends up tracking too much information for too little real benefit. I define benefit as the team delivering more working software features in production faster.

As Eric points out, one needs to track the following

1. Planned Work – What work is scheduled to be completed?
2. Cost Estimate for Planned Work – What is the cost estimate for the scheduled work?
3. Actual Work – What work has been completed?
4. Cost Estimate for Completed Work – What is the cost estimate for the work that has been completed?
5. Actual Costs – What costs have actually been incurred?
6. Variances – Cost difference, Schedule difference, Estimate Difference.

If you compare this to a Scrum burn-down chart, or a cumulative flow diagram, you’ll see there is a good deal of time that needs to be spent on overhead, instead of where management focus should be: identifying and removing constraints to the team delivering value. Also, I find this type of management information is too easily used (sometimes inadvertently) by the business to beat up IT on why variances between estimates and actuals are so large. What the business really cares about is seeing software features which they value working in production. Once you have a good idea of a team’s velocity, leave it at that. The velocity — or the number of features that you delivered last iteration — enables a good prediction of what will be delivered next iteration. Even if this does not work to plan, the business is generally very happy with getting a working set of features in production on time and within spec.

With the resources — be they money, manhours or a technical environment — you are using on implementing EVM, consider investing this in your team delivering software directly.

Technorati Tags: ,