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?

Why is successful software development so difficult to repeat?

Why is successful software development so difficult to repeat time and again like a factory?

Well it’s about people.  I think that sums it up. (Though it sounds rather crass as I read it.)

I want to discuss two issues.  First, I think many people ignore the fact that software development is actually about creating not manufacturing the same thing every time. Second, communication between even well intentioned people working together every day is fraught with noise and incoherence.  How can you build software if everyone involved is unable to communicate clearly?

I propose that we need to actively work against the assumptions that so much raw material that enters the software factory creates X amount of value because it creates a measurement biased approach focused on utilization as opposed to value delivered.  Software development management cannot be a game of Tetris-like management of hours by role as the project plan for perfect utilization. There are many efficiently developed software systems that have been developed that have not delivered anywhere near their potential business value.

Our ability to pay attention, to listen and then to understand complex concepts is difficult in the most simple settings.  In a more freeform arena such as custom (think green field) software development it is extremely difficult. This is played out daily all over the world as software projects fail, get delayed and miss on expectations of their sponsors. But it doesn’t have to be this way, we simply choose to ignore that development relies on an unreliable factor, human communication.

So what to do?  Create a new certification program?  Derive a new process? Self-improvement guru’s and methodology coaches have similar business plans.  Hey, sometimes it works.  I don’t like gambling on sometimes.

Eliminating the manufacturing/measurement mentality…

We need to change what we measure for success.  We need to suspend the efficiency experts for a moment and look at how to create real value.  There are not many CEO’s or investor’s that I have met who would complain about making a $2 million dollar software project investment to get $50 million in year over year annual revenue return.  (I know there are other costs for continuing operations, but that can be factored in and we can get logarithmic or even exponential scaling if we can design operations appropriately when we build the software.)

By focusing on value we also are better able to make value focused as opposed to process focused decisions. In the above example if we really needed one more QA for a few weeks, can we just pay for it and launch the project rather than argue about estimation methods and 14 step approval chains?  Go get that revenue!

Remembering people are imperfect communicators…

Project teams (everyone involved not just IT pros) can work to make the objectives easy to understand and model.  This involves breaking down artificial organizational barriers, barriers of understanding and closely held assumptions. Not just technical aptitude.  Yes, it involves more than normal commitment.

This is a prime principle of many newer software methodologies.  But it only works if we make the investment to reap the value.  We can achieve more coherent communication by developing common language to define our problem and create the necessary agreed upon concepts for negotiating and managing when we build the software together.

A collaborative creation process can’t work with a drop in interview or a conversation once a week.  It also can’t be done with lots of lingo that creates assumptions. So whether facilitated time together to let ideas grow and develop or a dedicated person who is a product owner embedded in a team every day, creating common experience around the language and concepts is critical to overcoming communication entropy which only increases over time.

Put it together…

The highly efficient manufacturing model actually dissuades dedicating the right time needed to capture the value we can create. If we suspend the manufacturing/efficiency model, we can actually evaluate and justify the right commitment of resources for a project/program/effort.  Applying solid best practices to reinforce coherent communication and clarity will allow for smaller teams to be more productive, more efficient and reactive to change.  Which is a real offset to the arguments in favor of the manufacturing/efficiency model.

And hey, it’s OK if something cool can’t be justified.  Probably needs to be tuned up or trashed. Better early, than investing poorly with incoherent communication for a bad result.

Wrap it up…

Does your company understand it is creating value with software or is it confused by the manufacturing model focused on efficiency?  Can your organization communicate effectively over time and actually increase the value expected and delivered with software? Write back and let me know or ask for help.

Gary

P.S. I am a voracious self-improvement reader.  Love it.  Sometimes it even works for me.  I keep trying.