Improving your process plan is as simple as ... well, it's a secret that Payson Hall wants to share with you in this week's column. This bit of advice has helped numerous companies and everyone involved in the process. Find out how Payson, formerly part of the development community, became one of THEM and learned this great secret.
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