It’s an odd title, I know.  But as a seasoned project manager and IT professional with over three decades of experience across multiple industries, there are some things that really don’t change much.  Among the is the concept that “done means done and in production” and anything less isn’t of much value.  So hang on while I vent a little regarding a topic almost every PM holds near and dear to his/her heart – progress updates on tasks and deliverables.

In recent articles, my cyber colleague Howard Weiner and I have talked about the role of Steering Committees and what questions should be asked and answered.  The substance of all updates for any project comes down to a really basic couple of questions: “How far along are you?” and “When will X be done?”  Through the years, we’ve seen multiple industries tackle the answer in different ways.

In construction, you can often legitimately measure progress along the way.  A 10-mile stretch of road needing to be constructed or resurfaced can legitimately claim 10% progress for each mile completed.  Buildings also offer similar tangible milestones toward the end result.  But even on these projects that are normally very predictable, we don’t get much value until we can drive on the road or live/work in the building.  And in attempting to translate this to software development projects, that’s where the wheels seem to fall off.

My Retirement Fund

If I had $5 for each time I had a developer state s/he was “35% complete” with a particular task, I’d probably be on my way to retirement.  And I might need to retire (or find another line of work) because taking such a status at face value is not only unwise, it’s usually a very unsound practice.  Some might even call it a touch of insanity – oh wait!  I think I’ve called it that.  While we can see tangible progress on the bridge, road or building at various points the same cannot be said for software development.

While the unfinished code or building are equally unusable, it’s just about impossible to accurately gauge programming progress the same way.  While variable exist on all tasks, software just seems to play by its own rules most of the time.  Add to that the rules seeming to change “at whim” and what’s a project manager to do?  I think the answer is almost painfully simple – if you can get the teams and organization to buy into the concept.

Ones and Zeros Rule

A task is either open or done.  And by that, I mean if there is any chance you will go back and revisit the work, then it’s open.  You only get credit for what you complete and that takes us back to 1’s and 0’s.  Now, managing by just that alone is equally insane, so you need to account for hours (or dollars) burned vs. what was budgeted, keep track of estimated time on tasks vs. consumed and other factors that you would normally do as a project manager. And if 0% or 100% is too hard of a sell, you can come up with some variation such as 5% when you start, 50% when you complete unit test or code review, and 95% when you complete final testing pending implementation.  But the point is, the fictitious “I’m 58% done with the task” has to stop.  It’s clouding the picture and it’s making your status inaccurate to a pretty significant degree.   Simpler is better and getting all the way back to “done” or “open” is really the simplest.

Finding Your Sweet Spot

The end goal is an accurate update.  And that update cannot be either one-dimensional or based on numbers that are little more than “fluff and stuff”.  I read an article a long time ago titled “Lying with Earned Value Management” and I’ve never forgotten the core ideas it set forth.  Companies far too often want a PM to report only good news (see my prior article about maturity levels for some insights there) and the squishy progress percentages support that right up until the point somebody gets reassigned or fired for a project gone sour.  I’m not saying finding the right way to report is easy, but it is worth doing.  It’s a sign of a maturity that seems to be lacking and, in an organization that really respects honesty, will be welcomed as a breath of fresh air.  It may not look like 1’s and 0’s, but it can be done if you as the project manager will find a way that works for your company.  Do it, and watch it spread.

Bio:

Mark Moore has held multiple professional positions in IT and business for nearly 
three decades serving organizations both small and large, public and private.  With over half that time as a project manager, he has successfully managed major initiatives spanning multiple years with a cost of over $3 Million and teams of over 250 people.  He has been a Project Management Professional since 2002, served as President of the PMI Western Michigan Chapter, and presented at multiple NCPMI Annual Events.  Mark holds a Masters of Education degree from Colorado State University with a concentration in Adult Education and Training.  He is an experienced writer, speaker and presenter on project management and team building topics.  Mark is the Principal Consultant for Broken Arrow Associates, LTD.  He and his family live in a rural area outside of Raleigh, North Carolina.  To contact Mark for opportunities or questions, send an e-mail to info@baa-ltd.com.