At what point to you stop trying to fix a problem with process?

[BizAnalyst]

I see a lot of people trying to fix problems by improving processes. In some instances this is a good idea. Processes are great for repeated tasks. Processes are handy to define workflow for a group of people. It's a good idea to share best practices. Processes can be wonderful.

But, I see people trying to fix failures in thought tasks with processes. Sometimes, it seems it would make more sense to realize you should just find someone better suited for the job. (Or, make it clear to the person that their job includes thinking.)

Plus, I have a sneaking suspicion that too much process gets people out of the habit of thinking and taking accountability.

Has anyone else been seeing this?

[gescober]

One of my favorite quotes from, The Art of Project Management, by Scott Berkun -

I've found that obsessing on process is a warning sign of leadership trouble: it can be an attempt to offload the natural challenges and responsibilities that managers face into a system of procedures and bureaucracies that cloud the need for real thought and action.

It is very tempting to reduce a project to a bunch of processes and checklists, when projects really are about the goals and the people. The reason why it's so tempting is that it's much easier to manage a process than it is to manage the people.

So, yes, I've been on projects where a team member was somewhat less than competent and hid behind processes. It usually meant that other people had to pick up the slack. I'm not a functional or project manager, so it's not really been my problem to resolve.

[BizAnalyst]

Thanks gescober, love the quote!

[ABadri]

I think that the problem is more insidious than just trying to fix problems with process. In many cases, the processes have become a proxy for what people do. A lot of what people do are process steps - it has become their job as opposed to being an aid to doing their job or accomplishing their tasks!

It is no wonder that people get very defensive when you try to change processes (or heaven forbid, eliminate a few altogether) - you are in essence changing their jobs or what they think is their job!! No, you are not alone in thinking that process tyranny trumps all common sense in people who are otherwise extremely intelligent and reasonable. Live in the weeds long enough and you even forget that there is a forest around you, let alone what it looks like :-)

Have fun and keep up the good fight, and no, you are not going crazy!

[achen]

I think that the problem is more insidious than just trying to fix problems with process. In many cases, the processes have become a proxy for what people do. A lot of what people do are process steps - it has become their job as opposed to being an aid to doing their job or accomplishing their tasks!

It is no wonder that people get very defensive when you try to change processes (or heaven forbid, eliminate a few altogether) - you are in essence changing their jobs or what they think is their job!! No, you are not alone in thinking that process tyranny trumps all common sense in people who are otherwise extremely intelligent and reasonable. Live in the weeds long enough and you even forget that there is a forest around you, let alone what it looks like :-)

Have fun and keep up the good fight, and no, you are not going crazy!

I agree completely that process is often times a reaction to mediocre people. Process should help support great people do their job even better. They should feel supported by the process not trapped. One of my favorite examples is checking in code. Back in the day developers didnt like to use source control at first. However once they started checking in code all of a sudden they realized how much effort it saved them. All processes should be about helping people to avoid costly mistakes.

The danger is that if I have to repeat a one minute process 1000 times to avoid a one hour mistake, that is not a good return on the process. Some people might work their way backwards from the one hour mistake and say "see, a one minute check avoided a one hour mistake!"

[MJMurphy]

This question, with a slightly different twist, came up today in a discussion about decision making. Is it important to try to improve the decision making process? We need to make lots of decisions in the process of getting requirements defined. Even small improvements should have big payoffs. Will better decisions mean better requirements? How much of a role should 'politics' and negotiation play in decision making? Having a well defined decision making process implies that things will go smoothly but in reality the process is often pretty messy. Is it a mistake to try to impose order? Should we just get people in a room and let them work it out?

[AlanAJ]

Is it important to try to improve the decision making process?

That depends on how good the processes currently are and what the costs are of moving closer to "perfection". How would you characterise a "good" decision? Actual outcomes may be better with a clear and timely, but otherwise sub-optimal, decision. And it's the outcomes we're interested in, isn't it?

Will better decisions mean better requirements?

Better decisions about requirements will mean better requirements, whatever that may mean. Sounds true by definition! Better processes cannot mean that every decision will be better, just that all the decisions considered as a whole are better (otherwise, it wasn't a "better process" after all).

Having a well defined decision making process implies that things will go smoothly

No, it doesn't. Only a poorly defined process would be founded on such an obviously erroneous assumption! Perhaps you are confusing clarity or aesthetics with effectiveness?

Is it a mistake to try to impose order?

It could well be. A wholly chaotic process is almost certainly sub-optimal, but so too is an inflexible, invariant process. As with any other process, you have to try to understand its strengths and weaknesses, relative to its purpose, before you seek to improve it.

Should we just get people in a room and let them work it out?

That's one process that has stood the test of time. But strictly it is only a process step. Which people? At what stage? With what preparation? Producing decisions or recommendations? Communicated to whom? How? When? To what ends?

[ABadri]

This question, with a slightly different twist, came up today in a discussion about decision making. Is it important to try to improve the decision making process?

Let me try and take this one on with a little "twist" of my own. With a tip of the hat here to Marc and Don Rumsfeld, here goes.

From a requirements standpoint, we have "known known" requirements. These are the requirements for the software that we know we want and are in the process of defining. Here, I would argue that methodology is the "process" that improves the "decision making process." Methodology ensures that we properly define project vision and business objectives, capture all (or most of) the functional requirements, have a means for traceability, etc. Implicit in methodology is a process for decision making - forcing the objectives to be clearly defined, defining scope that ensures requirements are gathered within the agreed bounds, etc.

It is within these boundaries that methodology creates / enforces that the micro or sub decisions are made - who defines the project vision, who are the subject matter experts defining requirements, etc. It is also in this realm that the political battles are fought and so on. So long as we are all playing inside this sandbox, the process improvements should lead to a smoother experience for all concerned but should not drastically alter the final outcome. Whether the project vision is defined in a rational civilized and friendly manner or after much hand wringing, emotional outbursts and metaphorical daggers in the back of unfortunate stakeholders is immaterial, so long as the project vision is clearly defined, understandable, quantifiable, etc. This is true of every step in the methodology.

The "known unknown" requirements for me lie in the realm of requirements around which there is uncertainty. For example, if you are building a web app and you do not know if the number of page views is going to be ten thousand or hundred thousand per day, then you run the risk of providing a non-functional requirement that is either wildly pessimistic or optimistic. But these kinds of situations to me are no different than any other discipline that requires decision making under uncertainty. Could better decision processes help in this? Perhaps. The important thing is that they are even considered in the first place. Here again, I believe that methodology and good practices are your friend. If you have used sound methodology, you have hopefully identified this non-functional requirement and not missed it altogether. If you are using good practices, you may have captured this as an action item and closed the loop on it or clearly identified this as an assumption so that the developers are at least aware of the uncertainty and do whatever they can to mitigate it. At the very least you have forced someone to just toss a coin and give their best guess estimate as to what the requirement might be in these scenarios.

On to the "unknown known" requirements. These are the requirements that everyone but the requirements engineer and development team thought was going to be in the product! This is where methodology is truly your friend. By using a standard set of proven principles and practices, you keep these to a bare minimum. We all know that we are never going to capture all of the requirements going in, but by capturing them in a systematic manner, the likelihood of having a whole bunch of unknown known requirements coming back to bite one in the posterior is minimized.

And the last category - "unknown unknown" requirements. Heck, even Don Rumsfeld did not have an answer for that one! Don't expect me to have a clue on it either :-)

[MJMurphy]

From a requirements standpoint, we have "known known" requirements. These are the requirements for the software that we know we want and are in the process of defining. Here, I would argue that methodology is the "process" that improves the "decision making process." Methodology ensures that we properly define project vision and business objectives, capture all (or most of) the functional requirements, have a means for traceability, etc. Implicit in methodology is a process for decision making - forcing the objectives to be clearly defined, defining scope that ensures requirements are gathered within the agreed bounds, etc.

I like the Rumsfeldian categorization but is it always true that the decision making process is implicit in the methodology? It seems like the methodology should tell you there are certain decisions that should be made at a certain point but how the decisions get made could be undefined. The team could decide to flip a coin for each decision or they could vote, arm wrestle, or defer to whoever talks the loudest. As long as they get decisions made wouldn't they be following the methodology?

[MJMurphy]

Actual outcomes may be better with a clear and timely, but otherwise sub-optimal, decision. And it's the outcomes we're interested in, isn't it?

Well, we're definitely interested in outcomes and I think that was the point of the discussion. Can we get better outcomes if we improve the decision making process?