Make Process Independent of People

 

I have an opportunity to review process documentation (actual and proposed) from many organizations. I admit, I have a prejudice for more Agile techniques (integrated into any lifecycle). But non-Agile techniques work too.

Here’s what I find doesn’t work: making the process dependent on the personalities of the people who have to carry out the process. One of the reasons a waterfall or phase-gate lifecycle more often fails than succeeds is because it’s dependent on the project manager policing the people on the project to perform all the paperwork deliverables. Now, these documents may well be valuable during the project. But as soon as the perceived schedule pressure becomes too great, the technical staff stops producing useful documentation. They may spend time on the docs, but they don’t serve the intent of the docs. Same thing with reviews (design reviews, code reviews, any review).

The process has to be independent of the people. Reasonable and capable people should be able to use the process to push back on unreasonable schedules–or explain why they won’t use the defined process. If the process pushes staff to stop using the process in the face of schedule pressure, depending on one person, the PM, to push back on management or the sponsor, the process is doomed. As soon as management pushes the crazy schedule button, the process goes out the window.

If you’re a process person, make sure the process you define is robust in the face of schedule pressure, and does not require one lone person to stand up for the project team, but allows the project team to stand up for itself.

3 Replies to “Make Process Independent of People”

  1. Thanks for this. Once again, this paints a nice picture of a solution for me.
    My Management has the freaking “Crazy Schedule Button” Duct Tapped to the console!!

  2. The issue I have is that in general, people would avoid planning or documentation altogether when left to their own devices. How do we manage the resources without falling back on phase-gates or other tools. Too many times I have heard good developers tell me they don’t have time to document or plan, they have to code then when the project blows up 3 months latter, they blame it on not being given the time to plan or design. It seems like a smoke screen at times. I feel the project team is responsible for delivering on reasonable milestones and there has to be a mechanism to audit the process so what alternatives do we have?

  3. IMO management consultant Lisa Haneberg has an answer for Rick’s question.
    I think his comments imply additional questions about his organization.
    How can it be that developers don’t have time to do their work? Who is setting the timelines for them?
    Who says ‘phase-gates’ etc. even work? Industry analysis groups like the Standish Group consistently find IT projects fail in the range of 70% to 85% of the time. Doesn’t that suggest ‘process control’ may be the problem rather than the solution? Isn’t that the main reason the Agile movement got started in the first place?
    Agile project teams don’t avoid planning or documentation altogether. It’s a question of emphasis. The end product is not a plan or a document, it’s working software that meets the customer’s needs. Plans and documents are only interim artifacts, and they are only valuable if they help the developmen team produce the real product.

Leave a Reply