Or how many people get so stuck in the processes of how to do the job, they simply forget to actually do the job. Many a product has failed to materialize because the process to make that product has gotten mired, stuck, distracted or waylaid. It becomes about the people and the politics and the process and no longer about the product.

I use this Hiltmonism to help me to focus on the goal, the reason we are creating the product, and the need to be ruthless in getting it done. We are doing what we do to make a product, to ship it, to delight our customers, and to make money. Not because we love following a process for the purpose of process following.

There are so many examples of when the process takes over, and the product never gets done:

• Too many head chefs: Projects that are run by committee or need to have “buy-in” from a multitude of people and departments get waylaid by the process to achieve consensus. The number of opinions and egos grows exponentially as the number of owners grow.
• Too many deliverables: Projects get slowed down in project management reports, process documentation, regular presentations and meetings instead freeing the Project Manager to lead the team and get things done.
• Bureaucracy: The growth of a bureaucracy as an organization matures is natural, but it leads to discussions on seniority and turf wars instead of laser focus on product.
• Used to Do X: The continued slavish performance of manual processes that distract and take up time just because “we always did X this way”. Look for processes that may not even be necessary any more as the business changed or another process covers it.
• Waiting For: Incessant “waiting for” others before one can do their task, and accepting this as an excuse for non-performance and an acceptable business practice. This leads to human deadlock, and the inability to move forward on a product.
• Minutiae: Getting lost in the minutia of a product, or “seeing a leaf and missing the trees and the forest”. This often manifests in management trying to solve all the problems instead of leaving that up to individual designers or engineers.
• Doing all the steps: Following strict adherence to a development methodology and process without actually creating the product, because the methodology takes over people’s time. Methodologies are good, but are not the all.
• Blame: Processes also assign blame, invariably to those who cannot choose the assignment, and folks don’t like to be blamed. So they do all sorts of crazy things to ensure they cannot be blamed or held accountable, spending time and effort covering their asses instead of making the product. And so the product does not get made.
• Fear: And good old fear of the unknown, so the product never even gets started. You can tell if this is happening when the team tries to solve all the problems that may never occur, just to be 100% sure that the product will work before even launching the project.

How to keep the impact of the process down and maintain focus on the product?

• Start with a light process. Do only the minimal amount of process to track the product development project and report on it, and focus more on the work of creation and building.
• Cross bridges if and when you get to them. Good product planning is worthwhile, too much over-planning means that you never stop planning and get started doing.
• Spike the known issues early and deal with the unknowns when they come up. If there are a few issues that are unresolved at the start, spike them, solve just them. Once they are sufficiently solved to move on, do so, and the rest of the product should be easier.
• Maintain clear and proper team communication, keeping folks in the loop and not hiding anything. Keep meetings short, make information available to all but do not overload or bore them with details.
• Delegate decision making responsibility. People who feel they have the responsibility to decide and to do something usually get down and do it. And if they depend on some one else’s work, give them the authority and responsibility to chase their dependencies up as well. That gets rid of the ‘waiting for’ mentality.
• Step back every once in a while and remember what you are trying to make and why. Look to see if the product is on track from a high level, then get back to the details.
• Fix instead of Blame. If an issue arises, and it will, all those who need to should get involved and resolve it. If an individual screws up, help them rectify and move on.
• Iterate a product, don’t try build it all at once. Aim for a minimum viable product, then take the time to flesh it out.
• Get parts of the product in front of users as it grows. Nothing motivates a team more than joyful acceptance of work done and excited anticipation of deliverables to come.

Many a product has failed to materialize because the process took over. Look for the signs, and remember, the process is not the product. The process is not what you do nor why you do it, the product is.

See also the other Hiltmonisms in the ongoing series.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.