The five "P"s in Project Management.
Yes, I know that there is only one "P" in the words, but there are lots of them in the way that we define and run projects. The five that are most important (although there are others) are Proposal, Planning, People, Processes, and Product. They can spell success if handled correctly and disaster if used incorrectly or ignored. This is not an in-depth review, but only an introduction. It is also not a "how-to" article, though there are some helpful suggestion nuggets included.
If you do all of your projects in house, you can skip this section. However, in today's environment, it is a highly unusual organization that does everything in house. There are two parts to proposals. One is requesting/evaluating them and is strictly a government responsibility, in most cases. The second is writing a responding proposal, which is a contractor job. This article will hit only the high points of both. For the requesting/evaluating tasks, there needs to be a good working relationship established with the contracting officer. We contractors are on our own for the response and proposal preparation, and this is done differently from company to company.
The first step is to determine the requirements. Good requirements are the basic structure of any successful project, as I'll discuss later, in more detail. What are the requirements for the proposal? The better defined the requirements, the better the proposal you write in response to them, and the better chance for overall project success.
The second major step is preparing the Statement of Work or Statement of Objectives. The basic difference between the two is that the SOW describes the work to be done; the SOO gives the desired outcomes, leaving the "how" to the contractor. Again, writing a good SOW or SOO is tough. Either needs enough structure and details to ensure that you get what you want, but enough flexibility to cover unexpected problems and opportunities. Too much structure or flexibility can lead to trouble. Usually the SOO will be the requirement that a contractor writes the proposal against, and it is issued as part of the RFP.
The third step is to determine the response time and the time needed to complete the project based on current in-house activities and available staffing. Being realistic with both timeframes is critical. Giving two weeks for contractors to respond to a complex and lengthy RFP is ridiculous. The government won't get a good comprehensive proposal if the turnaround is too short. The contract length is also important. Is this a six-month project or should you be looking at one or two years with option years? Contractors have to decide if it is worth bidding on. Does the company have the staffing required to perform adequately?
The final step is the evaluation of proposals. This is why a good working relationship with the contracting officer is very important. He or she will determine the evaluation criteria with PM input. Is cost the number one consideration, or is it past performance on similar projects? There are multiple criteria, and they are usually weighted in order of importance. The actual evaluation is normally done by a group that includes subject matter experts, contracts people, and others. The exact makeup of the Source Selection Evaluation Board varies and is based on the expertise needed to make a proper evaluation. It is important that the group have the right makeup, be unbiased, and do a thorough job of evaluating against the stated criteria.
There are many other considerations that have to be a part of the process. What type of contract (performance-based time and materials, cost plus, fixed price, etc.)? Should it be under a government-wide acquisition contract (GWAC) or blanket purchase agreement (BPA)? Is it a small business set-aside? Will it be open competition (unrestricted) or from limited invited sources? Will it be multiple vendors? What are the page limitations (if any)? Will there be briefings or a question period, pre- and post-award conference, and so forth?
Contractors are responsible for providing a good, readable, and understandable proposal. It must cover what the government is looking for, sometimes requiring clarification questions, the answers to which are provided to all bidding companies. The proposal should focus on the company's or team's capability to fulfill the requirements of the SOO/SOW, as well as any innovative ideas for meeting the requirements. The past performance should provide appropriate examples. The submission is normally divided into a technical proposal and a cost proposal. It must be on time and in the appropriate format. There is more required, but you get the idea.
I can't emphasize planning enough as a critical part of the project. The required planning covers a plethora of areas. Initial planning must include the budget, staffing, and schedule, not to mention all of the plans that are part of the project documentation.
Many projects are given a completion date before there is ever a project manager appointed to the task. Managers are normally forced to develop the schedule using the project completion date and working backwards to include all of the necessary actions. The schedule should be as realistic as possible. For a number of suggestions on making a realistic schedule and sticking to it, see "Quality Management ... A Primer (Defense AT & L, July-August 2005). Monitor the schedule and be prepared to be flexible and possibly revamp it. Chances are that you will have to at some point.
As with the schedule, the budget--at least, the initial budget--is set by someone else. It is a constraint that projects have to live with. Again, being realistic is a must: What can be done with the dollars available? Over-optimism has dented more than a few careers. Be prepared for changes because chances are better that the budget will be cut at some point than that it will be increased. Budget management takes good planning, constant monitoring, and sometimes a good dab of creativity. A little luck doesn't hurt either.
The other internally required plans are not the wasted efforts that many managers consider them: the project management plan, the quality assurance plan, the risk management plan, the test plan, and so on--seemingly ad infinitum (or ad nauseum, depending on your viewpoint). But they do more than just fill the squares--they all fulfill a worthwhile function. They help apply organization, structure, and scope to the project. They also provide the justification and basis for decisions on what will be done and how it will be done during the project's life.
I use the term "people" rather than "personnel" for two reasons: (1) it seems friendlier and less impersonal; and (2) more important, it covers more than just those working on the project. People include the project staff, associated subject matter experts, end users, upper management, and other stakeholders. All are important to the project.
Managers need good people for projects, whether they are employees or contractors. Having good people makes achieving success much easier. PMs need to be selective; personality and attitude are sometimes more important than experience or skills. The staff must also have the right tools for the project. For most PMs, the best course of action is telling the staff the schedule and what results are needed, then getting out of their way. Many times, because of their different skill sets and experiences, the staff will have better ideas about how to meet the needs of the project than the PM. But if you're the PM, you still must monitor their work and the results on a consistent basis.
There are a number of subject matter experts who will have to be called upon during the project. They include the technical experts, of course, but also might (and probably will) include financial, legal, contracting, logistics, and other experts who can help keep the project on track and out of trouble. A PM should never hesitate to ask for their advice and expertise, as well as have concurrence to get the right talent for the project.
End users need to be involved in the project from the beginning. They help determine the requirements and should be involved in the testing. A post-award meeting with the contractor is always recommended to ensure everyone understands the requirements, the goal, and the assumptions up front. Without end-user involvement, a project may end up with a product that is unusable, unwanted, or unneeded, and that's just wasteful spending of resources.
Without upper management support, projects don't get the things they need, like sufficient funding. Upper management are the project's champions, fighting for resources, acceptance, and support from others.
All the people mentioned are stakeholders. There are others, including those who will have to support the product, vendors, trainers, and outside agencies. The basic key to success with all of the stakeholders is good communication. Communicate up and down the chain. Let all of the outside stakeholders know what is going on. It doesn't have to be a continuous flow of communication, but the flow must be there.
Processes are the methodologies used to produce specific interim and final results, and they can include individual roles and responsibilities, activities, techniques, procedures, deliverables, workflows, tools, and measurements and metrics. While the definition sounds complex, processes can be simple yet still set the structure, framework, and baseline for a project. They ensure that things are done the same way each time and on a set schedule. Processes make it all fit together. Knowing that things are done the same way every time gives the project staff, management, and customers confidence that nothing is missed and that the results are trustworthy, useful, and usable. Processes need to be tailorable, flexible, and continually improved to be the useful tools that they can be. It is also good to establish a process that can be used to track successes and failures, as well as provide a base for future project planning.
Processes are a good thing, but they have their bad side. Processes are built from what has happened before and not necessarily from what is happening now or what might happen in the future. There are always the unexpected and the unplanned. Innovation and original thinking are needed during a project's life, and over-structured processes can get in the way of that.
There can be another problem with processes: Some people and organizations get so caught up in the processes that they forget about results. Results are what project managers get paid for. Managers and others can concentrate so much on developing or following the processes that they forget the true purpose: to end up with a product or outcome. Processes are the means to an end, not the end itself.
The product is what projects are all about and why we all have jobs. If we don't provide the right product, we have no reason to exist. Most projects result in an item of some kind, be it software, hardware, or other product for the warfighter or warfighter support. But it can also be a service, plan, recommendation, report, or some other outcome. Whatever the product, it is certainly the most important "P."
To end up with a useful and usable product, good requirements are a must. But good requirements are only the first step. Such a simple sentence for a complex activity. It requires user input, good analyses, a touch of reality, and finally, documentation of the requirements. Writing good requirements is an art, but it can be learned (see "Mission Possible ... With Good Requirements," Defense AT & L, Sep-Oct, 2005). Requirements must be identified, prioritized, and evaluated. Are they understandable, reasonable, technically feasible, doable for the dollars available, and prioritized?
Requirements change over time, whether we want them to or not. There is a danger in that; it's called "scope creep" (the unanticipated growth of requirements). Be very careful of scope creep. It can impact the cost and schedule. Another pitfall is gold-plated requirements. Gold-plated requirements are like gold-plated bathroom fixtures: they meet the need but are much more than is really required. For example, suppose a laptop is needed for a project. Gold plating might be a ruggedized (capable of being taken into the field), top-of-the-line laptop with wireless capabilities, when all that is really needed is a basic laptop that can be plugged into a network somewhere. The government is no longer looking for more bang for the buck; rather, it is looking to get the right item in the right place at the right time for the right price.
End users must be a part of the requirements process. They have the best understanding of what is really needed. It is best to get all of the players in the same room in the beginning. According to Brad Sabo, an instructor at the Air Force Institute of Technology, the Air Force has implemented the HPT (high-performance team) process to do this. Their process is an integrated product team. The team leader decides who needs to be present, who needs to be on call, and how they will proceed. The idea is to have all the right people in the room to ensure that the requirements are affordable, achievable, and testable. All requirements must be backed up by analysis. This brings together the users, acquisition community, testers, logisticians, and so on early in the process and has led to a much better set of documents. "Because of the high quality of the products that the HPTs have been turning out, we have been able to expedite the coordination and staffing process," says Sabo.
Another critical part of product (and process, for that matter) is testing. Adequate and timely testing with good test plans makes for good products and prevents major problems in the field. Projects can't scrimp on the testing. It will come back to haunt them. There should be multiple levels of testing, one of which is user testing (this applies especially to software). If at all possible, independent testers should be included. Timeliness is important, too.
The final major point is deployment of the product. What is the best way to get the product to the user in the most timely manner? Some products just go in the inventory, while others must be distributed to the end users in some way. A deployment plan is necessary and useful for most projects.
So it's important to be aware of the importance of Proposal, Planning, People, Processes, and Product in the world of project management. If project managers are not paying attention to these five, they can be headed down the road to failure. And if that is the case and they realize it, wholesale changes all at once may not be the right answer. It's like the advice on how to eat an elephant--one bite at a time. Make a change or set of changes, wait for the results, and then make the next change(s); and document, document, document! But in the end, what it comes down to is learning to spell project management with five "P"s.
The author welcomes comments and questions and can be contacted at email@example.com.
Turk is a retired Air Force lieutenant colonel and defense contractor. He is now an independent consultant. He has supported information technology projects, policy development, and strategic planning projects for DoD, other federal agencies, and non-profit organizations. He is a frequent contributor to Defense AT & L.
RELATED ARTICLE: Do you develop and implement PBL strategies?
Then you really need to know about DAU's PBL Toolkit.
The Performance-Based Logistics Toolkit is a unique Web-based resource, hosted by the Defense Acquisition University, that provides PMs and logistics managers a step-by-step process and readily available resources to support them in designing and implementing PBL strategies.
The user-friendly online PBL Toolkit is aligned with current DoD policy and is available 24/7 to provide--
* A clear definition and explanation of each PBL design, development, and implementation process step
* The expected output of each process step
* Access to relevant references, tools, policy/guidance, learning materials, templates, and examples to support each step of the process.
The PBL Toolkit is an interactive tool that allows you to--
* Contribute knowledge objects
* Initiate and participate in discussion threads
* Ask questions and obtain help
* Network with members of the AT & L community and learn from their experiences.
To guide you through the development, implementation, and management of performance-based logistics strategies--count on the PBL Toolkit from DAU.
You'll find it at <https://acc.dau.mil/pbltoolkit>
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||PROJECT MANAGEMENT|
|Publication:||Defense AT & L|
|Date:||Jul 1, 2006|
|Previous Article:||Six Sigma for the DoD.|
|Next Article:||Leading teams: ten top tips.|