Proposals/deadline creation

From Riley Consulting Wiki
Jump to: navigation, search

Proposal to change the method by which product deadlines are created

    The process under review is the one by which development deadlines, specifically those tied to the creation and launch of a new product, are set.
Current Process:
    The current process for setting product deadlines is based on the company-wide process for setting goals. Each year there are a set of large, year long goals set, called TOPS. Each TOP is broken into quarter-long segments. Each of those segments is broken into smaller goals call SMARTS. Each TOP is owned by an executive manager, meaning that they have repsponibility over that goal and all of its SMARTS. SMARTS are owned by anyone who wants to, though a SMART can only have one owner. All SMARTS are due at the end of the quarter, unless there is a situation where a SMART is due earlier. The due date of a SMART is never past the end of the quarter.
The Problem:
    The big problem with this system is that development products are lumped in with all of the rest of the SMARTS. For example, finishing Storm and integrating it with the other new product, Vortex, was the SMART owned by Brandon Cecala this quarter. The end-of-quarter deadline is absolutely arbitrary and false. There is no tech conference that the product has to be ready to demo at. There are not legions of customers threatening to quit if we don't get this in their hands immediately. It feels like upper management just wants everything done in quarters because that makes things nice and tidy and the spreadsheets look great. I have taken the opportunity to talk with our CEO about this very topic. He is of the belief that setting a deadline, even a totally arbitrary one, motivates developers to meet that deadline. This goes counter to the research done in this area and counter to the interviews I have conducted with the rest of the developers on staff. At best, developers will completely ignore the deadline and push ahead at their best pace. More commonly, the developers I have spoken with have expressed the feeling that the stress and anxiety that arises from trying to meet a milestone that they had no voice in choosing is entirely a demotivational factor. The people who have to work overtime to meet the deadline feel unappreciated and have no ownership or pride in attaining that goal, since they didn't agree to it in the first place.
Proposed Process:
    New development projects should not be tied to SMARTS in any way. A quarter is not necesarily the correct amount of time for a product to be built. In addition, the creation of the project timeline needs to be far more of a bottom-up process. A dialog between the executives and the dev team needs to begin early in the process, with a series of proposals going back and forth. Management should present the product they want made, from which the development team will create a formal product specification and estimated project timeline. The dev team needs to retain control over that timeline, meaning it cannot be changed by a manager. If upper management wants the product out faster than the team estimated, they need to discuss what features can be cut, following which the team will give a new, revised estimate. At no point can scope be increased or the timeline shortened without going through the team who have to have the authority to cut features or lengthen the timeline should either of those things happen.
Outcomes:
    This process has two primary benefits. The first is that it gives the development team a sense of ownership over their deadlines. They are the ones who set them after all. They were not arbitrary things that were handed down out of the nether. While this sense of ownership does not guarantee that moral stays high on the team, it at least removes the "my manager is an idiot for making us do this" cause of decreased moral. This also creates and environment where the team can learn and get better at estimating as time goes on. Inevitably the earliest project estimate will be little better than wild guesses. However, time and experience can refine this process to the point that the teams are consistently hitting their goals. That opportunity is not there if the manager is the one setting the goals, since the manager is too far removed from the nasty little details that make a huge impact on every project. The second primary benefit is that it helps to dispel the illusion that management is in control. The project will be done when it is done, and no amount of "managing" (at least not in the pathological sense) is going to change that. The people who can best estimate the completion date are the ones who have to get it there. Reinforcing the idea that management cannot control this project could help them to focus on the things that they can and should be doing, like removing roadblocks and protecting their teams. All-in-all, product deadlines should be set by the people making them and no one else. In so doing, the best possible product will actually be made as fast as possible, as the effect to moral and creativity that putting power and responsibility in the hands of the developers cannot be overstated.