Project Management Choose Quality or Speed?
“Myspace went too wide and not deep enough in its product development …. We went with a lot of products that were shallow and not the best product in the world. … [S]peed to market was essential.” Quoting Chris DeWolf in “The Rise and Inglorious Fall of Myspace,” Bloomberg Businessweek, June 27-July 3, 2011.
Similarly, I watched a Fortune 50 company for years insist on aggressive schedules that they never met — not even close — justified by the need to get to market first. The other reason often given for these same undoable schedules was that the “company will not survive if we don’t make it!” Well, they were right, but it was ten years before the damage done by this approach to developing products finally undermined the huge company enough that it was disassembled and sold into separate independent parts. There was plenty of time to get it right, but the culture, just like at Myspace, irrationally argued for speed.
Myspace, which “went with a lot of products that were shallow and not the best products in the world,” got to market before their competitors, but couldn’t hold onto that market. The Fortune 50 company above did on occasion get out a product that no one else had or otherwise was a smash hit, but its emphasis on speed always held it back on quality and made meeting promises of delivery dates an open customer joke.
If we can get there first, great, let’s do it. However, if we get there first (or stumble trying to get there first) but with low quality, it is not obvious that we are going to be viable in the long term. Sometimes the risk we need to take is not that aggressive schedule but instead the risk of putting quality first, which often doesn’t cost any more nor take any more time than putting speed first.
Is quality or speed the higher priority on your projects?
6 thoughts on “Project Management Choose Quality or Speed?”
Comments are closed.
Thanks Bruce. I will definitely read the book you have recommended. Anything that helps me practice my profession honestly and effectively…:)
Regards,
Ankit.
Bruce,
Once again I agree. What will help is some tips on how I as a project manager can help change a culture that demands everything yesterday. It starts with giving the right recommendation but after that there is limited resistance that I can apply against senior stakeholders.
Regards,
Ankit.
Ankit,
Here is where we use some change management and technology transition techniques. In one case, many months before the project got approved, I started a simple discussion with the team (and included senior managers – this was an e-mail chain) on how long our projects were taking. I outlined our past history and characterized how our abbreviated schedules resulted in some typical problems (milestones start to slip). I then outline how our reaction to these slips (more staff, more meetings, etc.) never had much impact (ever, actually) on getting us back on track. Finally, I outlined how we needed to put in place a better schedule, and simply start the project earlier (which was a bit of a swipe at the business manager and marketing for when they did things). This was all just an “educational” discussion.
The project was approved, with a very short schedule. As the project proceeded, and started to have problems, I’d point out on this same e-mail thread what would probably happen next – which then happened (I kept everything very objective and in a “gee, I wonder if this will happen here” tone). To fast forward to the end, the team — who had insisted they could make the schedule the senior manager wanted — convinced the senior manager they needed to “extend” the project a bit, which she agreed to. In the past, without the low level discussion about how things work going on, bringing up the notion that a project was off track and we needed to extend the schedule early on in the project (rather than just working harder) would have been met with scoffing skepticism.
The change management notion here is that people need time to adapt and internalize a new idea, especially one that is contrary to what they strongly believe. In a sense, it is being willing, periodically, to suggest the emperor has no clothes. And while we take heat each time we do this, over time the willingness to mention or admit this might be the case gets easier for these folks. At some point it becomes “common knowledge” to these folks and they suddenly act on it, as if “of course” this is what is the case. We have to let go of the notion that at some point we can say “I told you so” as this just undermines future change management efforts. Note, this works well when the notion we are advocating has solid reality to it (factually, statistically, hard data based). I had one business manager tell me at the end of the project “hey Bruce, this stuff really works!” But he fought me, hard, all the way to the end — telling me to stop talking or bringing up these notions!
A book I liked on “change management” is Change Masters by Rosabeth Moss Kanter.
Good luck.
Bruce