Getting A Project Approved Does Not Mean It Has A Good Plan
For example, we had a proposal to launch a new product in one year. We had never launched any new product in one year. The normal time to launch a brand new product was 18 months. Our group of senior account VPs who blessed all products apparently heard enough to give approval for a one year new product development.
Ultimately, this product shipped seven months after this originally approved ship date. Which was very close to our normal launch schedule. We did “rescue” this product early on (i.e., gave it a realistic past performance based schedule) and it in fact became one of our most technically successful launches even though the product itself was not the huge hit we hoped it would be. Even better, this product baseline became the springboard for a whole line of on time projects due to its high quality. Up until this point we were known for our edgy products but they were always shipped many months after we said they would be ready — and were always an iffy quality.
A Schedule Significantly Shorter Than Normal Is Bad
However, the fact this product began as a 33% faster than ever before project is something worth examining. One would expect a special effort to be going on to make this new approach a reality. Normally at the twelve month point in a product launch we would be receiving product hardware prototypes and be rapidly ramping up to full software development to bring the product alive.
As the software project manager, I put out a notice to all the global account teams that the software functionality we currently had in the pipeline was all they should expect to get for a product that would ship in 12 months. Amazingly and gratifyingly, their response was “yes, this hardware with the coming software — that would be a great product in that time frame.” I thought, maybe this was possible.
Other members of the product team, however, chastised me severely that we had not finished figuring out all the software functionality we wanted on the product! This was not good. It normally took us six months to work through the give and take of new worldwide requirements (e.g., what vendors could deliver what components by when). I also observed what I would consider no extra sense of urgency by the product team to nail down the “rest” of the software requirements. They were pursuing business as usual in a project that was to deliver 33% faster.
Teams Saying They Can’t Meet The Approved Schedule Is Bad
The whole thing then completely fell apart when the hardware team said they could not deliver a working prototype for nine months. That would leave three months to do what we normally did in twelve months. It was almost humorous at this point. The fact that we were still having “serious” discussions about how to make this work put me back at the “how is it possible that we are still having these discussions?” mind set. Neither software nor hardware could deliver in this time frame, yet we were approved by senior leadership to pursue this project.
I’m always torn between the notion that this should never have passed muster as a twelve month project and the notion that if we ever wanted to be able to do a product in twelve months, then we would need to take a chance like this. Yet my experience is that these things don’t happen on faith. I had a boss who once told me not to give people the real project management status, because it might discourage them. He felt that as long as they believed it was possible, it could happen.
Exceptional Results Generally Requires Approving Exceptional Plans
I’ve just never seen it happen that way. When we ever did something that made a huge difference there was always that central idea, a unique or insightful approach, that was the core reason why it was different this time. It was usually something painful to do (besides work around the clock for months!) and well defined and not just a PowerPoint slide with 10 indistinct reason why we were going to complete a project 33% faster than we had ever done in the past.
It was clear that senior management had the performance data to know that it was currently taking eighteen months to ship a new product. The challenge then would be to hear and accept how the team was going to do it in only twelve months. I have to believe that the senior team, hearing this revolutionary proposal, would have done something like ask for a special review and hear from each manager what they would be doing differently to warrant taking this risk.
Senior Project Approvers May Need Your Help To Get It Right
What I concluded instead is that this decision was just another “why not, nothing else is working any better” type of decision. The senior approvers didn’t feel a sense of responsibility for ensuring this product delivered when they approved it to deliver.
The company had achieve a cultural norm where neither the company nor the customer had any real expectation that we would deliver when we said we would deliver. Hence decisions on project completion dates, while discussed with great vigor, could ultimately come down to dates that would consistently slip many months. This was just the way it was. Anyone talking seriously about delivering when we said we would deliver was seen as naive and not in touch with the complexity of large projects.
Achieving Exceptional Results Requires Doing Exceptional Things
Achieving something exceptional usually requires … doing something exceptional. Rarely will we exceed expectations by just thinking we could do things better or by just setting a goal of doing things better. If we see decisions for faster or better results being made, without an accompanying — real and insightful — effort to achieve those results, then we may be seeing a slow death of responsibility. Our job as project managers is to ensure this management malaise doesn’t seep into our projects.
Are you seeing any signs of a slow death of responsibility in your projects?