Project Management Tools

Project Managers Repeat After Me: Software Development Is A Repeatable Process

I had a job interview for VP of Development.  The interviewing VP with a long history in the industry asked me a simple question:  Did I think software development was a repeatable process?  I said yes. I won’t describe the ensuing discussion except to say I didn’t get the job.  We didn’t even get to talk about project management tools!

I’ve heard similar things such as Six Sigma can’t be used in software development.  No two software efforts are ever the same so they can never be done the same.  Every software development is a science experiment.

Balderdash.

I tell people that for over 30 years we’ve delivered software projects on time and with good quality (for details, see Is Your Project On Time?). Do you think anyone ever believes me?  How about after we actually do it?  Early in my career folks would tell me “you just got lucky” or “you got an easy one.”  Later in my career I’d hear folks months and years after we delivered on time say things such as “we never did figure out how that was done.”

Software Is a Repeatable Process Like Driving to DisneylandWhether it is a waterfall approach or an agile methodology it is a process and it is repeatable.  We do it every day.  When I hear that software is not a repeatable process it usually comes from folks who have a hard time delivering working software when needed. They confuse the inability to deliver working software when promised with the notion that it is because every software effort is different.  We can’t do exactly the same thing on every software project, so we don’t know when it will be completed.

These folks are confusing the process with the details of the project.  Driving cross country is a repeatable process. If I drive to Disney World or to Disneyland the approach is the same: Plan, drive, arrive.  The fact that the details are different, we go in different directions to get to each location, we stop at different places along the way, we pay different prices for gasoline and food, we drive at different speeds depending upon the speed limits, are all just details of the requirements and the execution.  How we go about turning the requirements into a delivery, of our family, to each location has the same overall process and we can use the same tools in the same way.  The same applies to software intensive projects.

What is often not seemingly repeatable is delivering a project on time.  This is another case where we frequently confuse ineffective planning with problems of the process.  If I want to drive to Disneyland from Chicago and give myself one day or just one tank of gas, I’m probably not going to make it.  Using these kind of questionable project parameters makes it seem like the traffic lights, construction, speed limits, the size of my fuel tank, and other vehicles are all conspiring to slow me down but these are just normal factors in such a drive.  They only become critical factors when we do something silly like try to drive 100 MPH to get the job done.  When driving significantly over the speed limit other cars become a greater hazard.  The chance of being stopped by the highway patrol becomes a risk.  Suddenly slowing down for a traffic jam around a city or major intersection or construction becomes a high risk (and they guy right behind us trying to get to Legoland in a day threatens to plow into the back of our car).  The point here is that when we set project parameters (cost, schedule, scope) that are unrealistic relative to the performance of our organization then normally challenging obstacles instead become deadly hazards to project success.

Software Development Project Management JetYes, of course, if we took an airline we could probably get there in a day. Heck, if we took the corporate jet and flew directly – being picked up and delivered by police escorted limousine – we could be there in a few hours.  The problem here is that folks like to believe if they drive their teams real hard they will succeed which is often equivalent to believing their car can perform like a Learjet if they just drive fast enough.  I’ll buy a new project management tool (e.g., Porsche) and adopt Agile (new driving technique) that will get 10x productivity (can go 200 MPH) and we’ll make it, this time. Really. I promise. Check my math.

Now of course, someone always asks, well – why can’t we go that fast?  Prove to me that we can’t do it in six months. Just because we’ve never done it before nor has anyone else, why can’t WE do it?  This is where folks confuse the notion of improving the process with the current capacity of the process.  Why should it be so hard to just do things 20% faster? Many of the organizations I worked with would have achieved 100% on time projects if they could have just delivered 20% faster than what they had done in the past.   Why didn’t they?  Because it sounding reasonable does not mean it is not horribly difficult to do.  Horribly, because when I suggest that we – while also trying to improve our speed – just start the new projects 20% earlier and use the average schedule … this is usually considered impossible:  “We don’t know enough at that point in time!  Everything will change too much if we start that early! It is too late for our current projects!  We have other things we need to do, we can’t start on it now!”  This is one thing that is relatively easy to do (we’ve done it) when compared to figuring out how to quickly improve the process to get a 20% increase in speed in the current project.  We do want to increase productivity and speed and the silver lining, for example in just starting the project on time is that it also empowers improvement efforts to actually have an impact.

Software and many other types of projects are accomplished using a repeatable process that works well – when it is understood and managed well (see The One Perfect Project Management Methodology).  Too often we confuse the problems caused by aggressive schedules, insufficient budgets, and excessive scope with problems in our process or methodology.  I always recommend finding an objective way for setting these overall project parameters (schedule, cost, scope) but for which ever approach we take, if we get these parameters in the right ballpark then our project teams will be – repeatedly – successful.

Thank you for bookmarking and sharing these articles as this tells me which ones are the most helpful.
  • Digg
  • Twitter
  • Facebook
  • LinkedIn
  • StumbleUpon
  • del.icio.us
  • Yahoo! Buzz
  • email
  • RSS
  • Reddit

Filed Under Planning | 10 Comments

« go back — more project management hints and tips »