Before 'Z' -- A Simple Secret for Process Improvement

The poor reputation that the software industry has for delivering large development and integration projects late and over-budget is well documented and doesn't appear to be rapidly improving. Organizations that sponsor large-scale projects in both the public and private sectors are trying to address the failure rate in several ways by:

• Formalizing and standardizing software development processes,
• Improving project management practices, and
• Instituting programs of periodic project reviews and assessments.

Since the first two bullets require that someone (maybe you) develop more effective processes or policy documentation, this short essay is designed to share a secret to help you do it better, faster, and more efficiently. But first, my point of view and a confession--I do project reviews (third bullet) for a living. That's right--I've become one of them. I used to be one of us (the development community), but after spending the first dozen years of my career supporting business applications in production, then developing commercial software, then doing large-scale custom development and systems integration, I embarked on a consulting career. A big part of my current practice involves doing health checks on projects. I wear a suit and tie, consult to senior management, and write project assessments ... definitely one of THEM.

A review typically involves checking under the hood--interviewing the project manager and team; examining work products and plans; and offering opinions about the health, risks, and viability of projects. Reports typically include acknowledging effective practices that are in place and making recommendations about process improvement (where applicable) for definition, planning, status reporting, tracking, etc.

I don't have religious issues about what constitutes a good practice. If the team has a documented and reasonable way of doing something that gets the job done and it isn't inconsistent with an organization's standards, I'm fine with it. If a team elects to re-invent the wheel, and their wheel isn't as round or doesn't work as well as an available standard or template, my job is to make sure they are aware of the limitations of their approach and how to address those limitations.

Recently I reviewed two planning artifacts for a large software procurement and implementation project: their communication and risk management plans. The communications plan was good. It identified who needed information, what information they needed, when they needed it, how it was supposed to be sent, and who was responsible for sending it. The risk management plan was fair. It talked about the processes that the project intended to use for risk management, the data that they were gathering, and how it would be used. It was mostly complete, but a little difficult to follow.

I want to share a valuable insight with you, whether you are a team member, project manager, or reviewer. Reflecting on the differences between the two documents and my impressions after an initial review lead me to realize that it is helpful and important to explain WHY you are creating any policy.

Both the communication and risk plans included a section titled something like "Purpose of this Plan" near the front. The communication plan said essentially:

"This implementation project is expected to last for several years and will dramatically change core aspects of how our organization does business at several sites. The goal of this communication plan is to describe how project information will be distributed to the people who need it as the project progresses. This includes the team, the stakeholders, and the community that will use the system. This plan records our current thinking about what information must be distributed, who will create it, who will receive it, and how often it will be distributed. We are creating this plan so that we can record our initial decisions and use the plan to guide project communication in the future. Should communication need change, we will revise and redistribute the plan to the affected parties to assure that expectations are managed and agreements are clear."

The section did a pretty good job of explaining why the author was bothering to write a communication plan. It provided a good framework for the rest of the document. It oriented the reader (me in this case) to what the author was trying to accomplish and gave me a context for my comments.

The risk management plan also had a section titled something like "Purpose of this Plan" near the front that said essentially:

"This Risk Plan is intended to fulfill our obligation under organization policy section 123.a.b.c which says that a project meeting criteria X, Y and Z must have a documented risk management plan."

Although I am paraphrasing a bit, the original text was nearly this stark. It seemed that the author was not particularly pleased with the assignment to create a Risk Plan. It also was not clear that the author understood the purpose of a Risk Plan, or saw any useful reason to create one for this high-risk, mission critical project. Much of the document read like it was bits of a template that had been filled in begrudgingly, not a coherent document intending to explain how risks on the project would be identified, analyzed, and managed. As a reviewer, I had little context to provide feedback. If you don't know the author's intent, it is difficult to review for completeness and consistency.

Here's a big idea for those of you who must write policy and procedure documentation:

Take the Time to Explain Why.

A short explanation of why you bother to document a policy is useful in a variety of ways:

• Orient the author(s) to the purpose and boundaries. This can be surprisingly helpful to you as an author in terms of keeping things brief and focused.
• Help the reader. If a reader knows why a policy was created, they can begin building a model of how that intent was addressed that facilitates understanding.
• Provide a context for later review and assessment. Sometimes policies initially accomplish what they intend, but the problem or the environment changes over time. Establishing a clear context for the problem you are trying to solve helps to set a baseline for evaluation/re-evaluation if the solution or the problem don't align at some point.
• Encourage compliance. Very few people like to do things simply because they are told to do them. Explaining the whys of a policy can help reduce resistance. Don't tell people, "All code will contain comments because that is the standard." Tell them, "Because we want to facilitate later maintenance and enhancement of our system, our standard is to include meaningful comments in all code."

If you take the time to describe a compelling reason for having a standard practice, it makes it easier on the writer, reviewers, and the poor souls who have to implement the standard or comply with it. If you can't come up with a sincere justification and explanation for why you are taking the time to write something down, maybe it isn't worth doing and THAT should be addressed.