Quality management--a primer: Part I.

According to the Merriam-Webster Dictionary, a primer is a small introductory book on a subject. I can't stretch this into a book, but it is the first of two articles on quality management. Don't expect articles on managing quality, although that will be touched upon, but accept them as an introductory text on providing quality project management. While they're aimed primarily at DoD software-related projects, most of the principles can be applied to any project. I hope it will provide a roadmap with some helpful hints for new project managers and food for thought for those who have been around for a while.

This is just a primer and doesn't have comprehensive coverage of any of the topics. So be prepared to do some research or ask questions of others for more detailed knowledge in any of the areas covered, plus any not touched upon.

Part I will focus on getting the project started, building the right team and the right team dynamics, and using good processes to end up with good, useful products. Part II will focus on budget, schedule, contractor relations, and a slew of points covering the many and varied other parts of project management that you have to worry about--like communications, setting expectations, quality assurance, and testing, to mention a few that might whet your appetite.

[ILLUSTRATION OMITTED]

Getting Started

One of the first steps is to assemble the project staff. It sounds simple, but there are many actions required, especially if this is a project that involves contractors. (The contracting actions are another article, so we'll bypass that and assume that the contract or contracts have been awarded.) As the project manager, you need to build a staff that can get the job done. You need the right mix of expertise, creativity, flexibility, enthusiasm, and experience. Don't forget the space and equipment that the staff will need to do their jobs.

In this age of contracting out functions that are not inherently governmental, many of your staff will probably be contractors. In the last half-a-dozen contracts that I have been involved with, as well as most of those that I am aware of, government and military staff were in the minority. In some cases, you might even have contractors helping to oversee the work of other contractors. While you should consider the contractors to be an integral part of the team, there are rules that must be followed. Your contracting people can educate you on those rules I'll talk about contractor relations in Part II.

Determine what functions are needed and find the right people for the jobs. Among the slots that you might need to fill are:

* Program/project management support

* Subject matter expertise

* Quality assurance

* Risk management

* Logistics

* Testing

* Engineering

* Contracting

* Budget/financial management

* Configuration management.

This isn't an exhaustive list, which makes it sound as if you might need a cast of thousands--and for a large, multi-million dollar project you might. But for many projects, the same bodies can fill multiple roles, or you may have matrixed personnel. Many of your personnel decisions are going to be determined by your budget, so keep that in mind as you plan. Remember too, that as a project grows or changes during the life cycle, personnel requirements will change.

Gather, prioritize, coordinate, and validate the requirements for the project. Again, there are complete articles on requirements gathering, requirements writing, and requirements management (see "A Template for Success," Defense AT & L, March--April 2004). Good requirements are the basis for success in any project. Without them, you don't know what you're building or if it will be usable when you finish.

As a part of requirements gathering, there are usually other data to be acquired and reviewed--equipment information, user metrics, vendor data, and more. Make sure that the data collected are meaningful, useful, correct, and needed. It's easy to waste time gathering and reviewing information that is unneeded or not helpful--and it happens frequently.

Promote Positive Team Dynamics

You now have your team, and it's up to you to get them working together to get the job done right, on time, and within budget. The biggest help in overcoming the challenges of a project is good communication. Frequent and open communication is a necessity. This doesn't mean just within the team, but also with the future users, the development contractors, points of contact within DoD or the Services, and those monitoring your progress.

Select the right person or group to accomplish any specific task. Once you pick the right one(s), ensure that they have a clear picture of what needs to be done. That means clear definitions, realistic expectations, and defined standards of quality. Too many times, a person gets a task, but the task comes without enough guidance. The person ends up doing what he or she thinks is needed, and that might or might not be right. When everyone has common understanding and expectations, it can save loads of time and money from delays or rework.

Schedule project reviews on a regular basis. Interim project reviews are a great tool for communications and even motivation. There are two types. One is the internal IPR for the team to share information with each other and the project manager. The other is for the project manager to share information with management and/or the customers.

Promote other good teamwork practices. These include good feedback loops, both internal and external; good documentation of plans, progress, and problems; ensuring that at least two sets of eyes look at every document; encouragement of creativity and flexibility; quick problem resolution at the lowest possible level; and a good capability for sharing files and data electronically.

All of this is just good common sense, but it's surprising how often these practices can be forgotten or missed. In the press of daily business, deadlines, and attending to the inevitable crises that arise, managers sometimes push good practices aside while they worry about whatever current fires they're fighting. But in the long run, that only causes more problems.

Products and Processes

The previous section leads right into this one: building and using good, strong, repeatable processes. Processes can make the pieces of the puzzle fit together easily. Knowing that things are done the same way every time gives the team and customer confidence that nothing is missed and that the results, whether a document, an action, or a product, are trustworthy, useful, and usable.

Begin with established government, DoD, Service, or agency standards and processes. They set the structure and baseline. There are many published processes within DoD that are excellent. But don't stop there. Look at other public- and private-sector ideas, standards, concepts, systems, benchmarks, and processes. The Government Accountability Office is a great source of information on government best practices. Don't reinvent when you can leverage on previously developed and proven work. Which processes and products you review and use will depend upon your project. You don't have to learn it all by trial and error. Don't hesitate to talk to others with more experience. Get them to share what worked for them and what didn't, and consider that homework. Lessons learned reports from other projects are another great tool.

Develop an ongoing evaluation process. This should include evaluation of your internal processes, products, and documents. Ask how these can be made better, faster, easier, and cheaper. Evaluate what works and what does not for your specific project. An integral part of your evaluation is a look at metrics and measurements. Metrics must be quantifiable, measurable, and limited in both scope and number. Use them to measure things that are within your control. There are many good guides and articles on metrics. That is another part of your homework: learn about metrics.

There are two types of documentation. The first is documentation on the project, processes, and personnel so that you have information you need when you need it. It provides the background and an audit trail for everything that has been done on the project. It doesn't have to be extensive, but it does need to be comprehensive. By that, I mean that you need to make notes--on a daily basis if possible, but at least periodically--about what has happened, what has been accomplished, what the problems were, and how they were overcome. This log or diary will help you answer the questions that arise and can protect you. It also provides lessons learned for yourself and others.

The second type of documentation includes those papers or electronic files that are needed to meet management requirements or regulatory guidance. These are the plans, schedules, analyses, documents, and reports that many managers see as wasted effort. While I, too, have felt that way at times, it turns out that most of them are worthwhile. They do more than just filling the squares: they help apply organization, structure, and scope to the project, if nothing else. They also provide the history, records, justification, and basis for decisions on the project and what you have done. They will help you answer the questions that I guarantee will come.

When the documents are prepared, ensure that they are reviewed, edited, and checked for accuracy. Look at them for content and appearance. Bad grammar, errors, typos, and wrong or missing information can damage the document's credibility, hurting both you and the project. It is also good practice to have a subject matter expert review documents for technical and functional content.

While you need to coordinate documents, especially draft documents, for inputs, when it comes to the final version, coordinate for approval/disapproval, not as a question or as a request for input. If you continue to ask for or allow input, you will never get the document finished. Of course there are people out there in management positions or in other organizations who will keep giving you inputs and changes whether you want them or not. That is something that you may have to live with, but good internal reviews should minimize it.

Other Processes

There are many other processes that you need to put in place or review. The following are a few to be considered early in the project. I'll talk about others in Part II.

Develop a problem-resolution process. Problems are going to arise. They may be technical, financial, equipment-related, differences of opinion, or personnel problems. Having a process to resolve problems can save you headaches. And the "process" of you, the manager, resolving all of the problems is not the best way to do it. Ensure problems or obstacles are brought to the attention of the appropriate people--the right people in the project and those in other organizations where you need support. This is where the buy in and the champions really pay off. You will be coordinating or asking help of others. Getting to the right people moves things along faster and prevents delays or wasted effort.

A good risk management process is another necessity. Don't make it a paper shell just to check the blocks. Use the process to find those risks that could have a negative impact on the project, and diligently work to find strategies to overcome, bypass, resolve, or mitigate the risks. Otherwise there might be unpleasant surprises in your future.

Standardizing terminology, data, elements, and processes is something else that will pay off. In many cases, it's already been done, and you just have to find what you need and share it with your team. Or someone on the team may already have the answers. Standardization gets everyone working from the same sheet of music, to use a cliche. That is a part of configuration management. Ensuring that the same versions of software, documents, plans, and schedules are used by everyone is important. The same goes for the products for testing and delivery. Configuration management is just one more of the processes that you need in place.

[ILLUSTRATION OMITTED]

A Warning

This section will be deemed heresy by some, but it is founded on 30 years of experience. Processes are a good thing, but they aren't the be-all and end-all for a project manager. Processes are built from what has happened before and not necessarily from what is happening now. There's always the unexpected and the unplanned. That's the time for the creativity and flexibility I mentioned at the beginning of this article. Innovation and original thinking may--no, let's say will--be needed at some point in a project's life. In many projects it will be more than once.

There is another problem with processes. Some people and organizations get so caught up in the process(es) that they forget about results. Results are what project managers get paid for. So don't get so caught up in developing or following the processes that you forget why you are there: to end up with a specific product or outcome. Processes are the means to an end, not the end itself.

Wrapping Up Part I

Project management is an art. This article gives you a part of the palette of paints to work with. Next issue will provide more colors. Remember that no two projects are the same. Some principles and processes will work all of the time, and others will help in most projects. The ideas and suggestions in this pair of articles are not comprehensive; they are basic building blocks. Books have been written on the subject of project management and on many of the topics mentioned here and in the next article. Consider this two-part primer as a distillation of some of those that can help make you and your project a success. For the new project manager, it can appear to be a daunting job with pitfalls galore--and it is. Yes, it's tough, but it's also one of the most rewarding jobs in the world.

Turk is a retired Air Force lieutenant colonel and a project manager with SRA International, managing two National Guard Bureau information technology projects. He has supported projects for DoD, the military services, other federal agencies, and non-profit organizations and is a frequent contributor to Defense AT & L.

The author welcomes comments and questions. Contact him at [e-mail]