Track Results, not Effort in your Software Projects

Measuring effort, is not the same as measuring to meaningful results.

So what is a plan?  I work in the world of software development and plans are easy to build and hard to deliver on in most cases.  There are many reasons for this and these are the subject of many blogs, posts and articles.  Have at it.

Here is my newly simplified viewpoint.  It can’t be a plan if everyone hasn’t agreed it is possible.  Yes, everyone wants it faster cheaper (even free!).  But if even one person can’t actually deliver on their work, the plan and  corresponding schedules and resource commitments are at best a fantasy or fiction if your prefer.

In doing some background reading, I found this existed as a principle in Extreme Programming. No one even talks about it anymore that I can see. Maybe my viewpoint is limited.  While the concept of team involvement, estimation and working as a group collective towards an end exist still, this commitment concept was left behind.

People need to be able to commit to what they believe can happen and what they believe they can do.  This is commitment based planning.  They need to change their reference for how they give information to encompass all of their work, it doesn’t come for free.  But continuing the thought, I have been a magician who has committed to people that my teams can make magic happen.  Let’s just say it didn’t always work, and when it did it was because of my team not because of me.

Rather if every element of the plan is reasonable and can be committed to by everyone, isn’t that the best starting point?  Then once we start, we can work on optimization.  We can measure actual progress for completed items as opposed to effort and know our actual rather than perceived progress.

For example, a simple plan with 5 actual pieces of work is created.  If everyone knows they can make it and we measure only to actually completed pieces of work, not fuzzy milestones like ‘development complete’ but rather “Can we process a payment?”, then we can measure real progress for software development.

On the flip side, if we measure progress against process steps, no one actually has to “complete” anything.  They can make efforts and then pawn the rest off on someone else.  “Hey, I checked that in earlier this week.  I am done baby!”  Three critical errors later and weeks in QA cycle because of poor development it is clear, this person never really ‘completed’ anything other than a skeleton solution.  A factory model of software measured by process steps as opposed to actual work completed definitely creates this type of environment.

So look at your plans.  Are they based on what can actually be accomplished and did everyone get to sign up for what they believe in?  Are you measuring real progress against actually completed items or just effort to milestones?.

Which type of plan would you invest in if you ran the company?  Which type of plan management do you believe will make real verifiable progress?