Part 2 – Product Development SOS … Why is the Schedule Elusive?
October 9, 2009
Why are product development schedules so elusive, seemingly like trying to hit a moving target? I have never been involved in nor have I ever heard of a project having gone according to plan. This is particularly crucial in a start-up because sales can’t sell what R&D doesn’t have available, and investors don’t fund hype and vaporware for very long. A staff almost always creates a schedule starting from the present and works forwards in time; rarely considering disruptive events that halt progress for awhile. Management almost always starts in the future and works backwards in time with contingency plans to mitigate risks that occur along the way. Management thinks in generalities and company-wide implications, and the staff thinks in details and specifics of their own job functions. How to do get the two to act as one?
A process I have followed is to present the project to the staff and first let the technical staff define its schedule from the bottom up. I have often instructed my managers not to voice their opinions prior to the staff deriving their schedules. I want the staff’s honest input. I don’t want the staff to try and please their managers by telling them what they think the managers want to hear. Once a clear idea is established as to what the technical staff thinks is doable, then it is possible to influence the schedule with a top down approach.
A bottom up approach is more difficult than it appears. As someone who has been involved in R&D for many years, I’ve found technical staffs love to complain about the schedule. It’s a favorite corporate past time. Management and THEIR schedule become the convenient and comfortable scapegoat that can be blamed whenever the project doesn’t go as expected. However, when given the opportunity to define their schedules, the staff complains just as much. The most common complaint is they don’t know every intimate detail of the proposed project and therefore don’t want to be held accountable for inaccuracies in the schedule. It as though they want to define a forward looking schedule on hindsight instead of experience. I have found staffs to be 25% to 33% overly optimistic. On a conceptual level, the project always seems less complicated than it actually is and ultimately, the devil is in the details. Likewise, they never account for all the little things that go wrong like network problems, resource sharing issues, power outages, software licensing problems, personnel turnovers, materials delivery delays, and so on. Management tends to trivialize the design complexity of the product features and overemphasize business considerations.
I have further emphasized this bottom up approach by using the staff’s schedules to determine individual milestones for performance reviews and bonuses, as well as making the staff manager’s dependent on how well his/her direct reports meet their individual milestones. I prefer quarterly bonus plan because people will work harder to be rewarded in the short term.
Most schedules are derived at the inception of a project and projects often take years to complete. The future is uncertain and the market changes as the project is underway. This is a particular problem with high tech start-ups where the original product concept can be a very distinct relative of the one that goes to market. This sends the product schedule into revision and technical people dislike chaos being thrust into their efficient and beautiful designs. If everyone is to truly “buy-into” the schedule then they had better be included in its creation and feel their input is recognized and valued. False buy-ins do no one any good. I worked with a manager whose group reported being 99% complete for more than a year. Only to have him leave and subsequently discover the group was less than 50% complete with their portion of the project.
Ultimately what matters is reaching the goal within the desired time frame. The schedule is merely a tool. This is really a people issue with getting people to perform their seemingly disparate, individual tasks and to listen to the needs of others in the organization. The goal is not the completion of the product development phase, but the success of the product in the market place. Everyone needs to adapt and be flexible. Schedules can be aggressive, realistic, and attainable, but should always involve the participants in the changes.
Filed under: Product Development,Team Building
Leave a Comment
TrackBack URL | RSS feed for comments on this post.