Quality management--a primer: Part II.
After you follow the advice in Part I to help you get your staff assembled, decide who's doing what, and gather the requirements for the project, you're ready to move on. You have your team in place, and you've built some great team dynamics, put some good processes in place, and started on all of the documentation that you need--but there's still a long way to go. You can't go anywhere without money and a plan.
Meeting the Schedule Challenge
The project schedule and budget can be the most difficult parts of a manager's duties. Meeting the schedule and staying within budget are critical to the real and perceived success of any project. If you don't meet the schedule for your project--even if it is through no fault of yours or your team's--the project is deemed a failure. The same holds true for over-running the budget.
Many projects are given a completion date before there is ever a project manager or a team. If that happens, consider a two-pronged approach, develop a schedule using the completion date and working backwards to include all of the necessary actions; decide if the schedule is realistic. If not, develop a schedule without the constraint of the given completion date. It then becomes your job to sell the new schedule. You may have to find a champion to sell it for you. There may be operational reasons for the original end date. If so, you are probably stuck with the original schedule. Throwing money and resources at the project might be possible--but with some projects, that won't help. Slitting your wrists or quitting could be considered, but there are far better options.
Finding ways to compress a schedule is a challenge for your whole team. Ask their help and listen to their ideas. Usually, the best way to compress a schedule is to make as many of the tasks as possible parallel rather than sequential. For example, it is sometimes possible in the software world to develop the software in modules. Work can proceed on multiple modules at one time; then testing can be done on each module as it comes ready, with final integration testing done at the end. That's just one example; there are many more around. This is where the creativity and flexibility that were mentioned in Part I of this article come in.
Let's get back to the project. You've determined the schedule--or at least have one that you think you can live with. Put it on paper or post it electronically to give the team access to it. They're the ones doing the work, and they need to be able to see how they are doing and what's coming in the future. Management will also want to see it. Make sure that it's realistic, and keep it a living document. Change or update it as the project progresses.
The following are a few other suggestions that can help you meet your schedule--certainly not all-inclusive, but they are a start:
* All tasks should have a timeline or suspense.
* Ensure that each task is assigned to someone.
* Do not accept or assign tasks that are unnecessary (this can be difficult).
* Do not allow "scope creep" (adding or expanding requirements as you progress--also very difficult).
* Consolidate tasks in the schedule where possible.
* Make tasks sequential only if they have to be.
* Set up a tracking system for tasks, suspenses, and action items.
* Review the tracking system at least weekly.
* Meet all suspenses as early as possible, and do not delay completing them until the last minute.
* If a task deadline cannot be met, ensure that the initiator and the task manager are notified ASAP and well before the due date; this may not help keep you on schedule, but it can keep you out of trouble, or at least minimize the trouble.
Balancing the Realities of the Budget
As with the schedule, in many (if not most) government projects, your budget--at least the initial budget--is set by someone else, and it's a constraint that you usually have to live with. Chances are better that your budget will be cut at some point, than that it will be increased. So how do you live with the budget and succeed? It takes good planning, good management, constant monitoring, and sometimes some more of that creativity. A little luck doesn't hurt either.
If you're the one planning the budget, whether it is the initial budget or a subsequent year's, make sure that it's realistic. I have found planning three budgets can be very helpful. The first is the fully funded budget. This is the ideal budget that you need to do everything required in the project and some desired but not required things, and it includes some funding for the unexpected. The second is a no-frills budget based on what you need to do the job and expect to get. This is normally less that the fully funded budget but enough to allow you to accomplish all or most of the necessary actions within the project. The third is the subsistence budget, the amount needed to keep your project alive and to accomplish the minimum necessary project requirements. It's the budget that you don't want but have to be prepared for.
With all of the unknowns and the many external constraints that come along, planning the budget can be difficult. I recommend that you try to keep a "management reserve" for the unexpected (a practice that is frowned upon in many quarters, but can save your professional life). It should be a percentage of your total budget. The following additional suggestions are for remaining within your budget. A few coincide with suggestions for remaining on schedule. That's because schedule overruns and cost overruns are usually directly related.
* Don't allow scope creep unless the dollars accompany the new requirements, and even then, try not to allow it.
* Track costs closely and compare them to planned costs.
* Project upcoming costs and revise them as changes occur.
* Use Earned Value Management in some form.
* Consolidate tasks for cost savings.
* Leverage on previously developed work--if you can use something that someone else has already done or paid for, do so.
* Don't use "gold-plated" requirements; that goes for personnel, purchased items, and the requirements for your project deliverables.
* Use cost-benefit analyses to help you make decisions.
* Don't waste resources on unnecessary work.
* Do things right the first time; rework is expensive in dollars and time.
* Prioritize requirements and tasks so that you know what can be eliminated if budget cuts come along or you begin to run over budget.
* Take immediate action if you appear to be running over budget. Waiting won't help.
* Scrutinize contractor and vendor invoices for errors.
Managing Contractor Relations
In today's world, almost every project has contractors involved. Below are a few suggestions for how you can ensure that the contractors help you make the project a success. Admittedly, as a contractor, I may see things from a different perspective, but I have been on both sides of the fence. Some of these suggestions apply to all members of the project team, not just the contractors:
* Make them a part of the team. Many contractors feel real ownership of a project that they are involved in Treat them as you would any other team members. Do not make it an us-them environment.
* Remember that the contractors have a scope of work, too. Don't expect them to accept scope creep either. If it happens, expect a contract modification that will cost you more.
* Let them know what you expect, but be consistent in the standards that you set. Set high standards for all members of the team and ensure that all live up to them.
* Give them all the information that they need to do their part. Open communication is essential.
* Accept that contractors have proprietary information or processes, just as you do. Don't share one company's proprietary information with other contractors. And don't favor one company with information not shared with all.
* Don't miss deadlines for completing actions or providing needed information to contractors. If you do, don't expect them to make up the time for you.
* Give them realistic tasks and timelines.
* Don't try to subvert the government contracting rules. That can get everyone in trouble.
Odds and Ends
... for a successful end to the project. If you've read this far, I hope you've picked up some good ideas. Here are a few more suggestions that don't fit into a single category but can really help you and your project.
Maybe the most important part of project management. Make sure everyone is aware of what is going on. Communicate up the chain, with your peers, and with your team. Keep your boss informed of the good and the bad. Let him or her know what is happening with the project on a regular basis. Communicate with the team. Give them feedback on their work and on the project status and plans. Keep them informed about what is happening, what changes are occurring, and why. Communicate with others outside your organization who need to be kept in the know. Communicate with the end users.
Ensure all levels of end users are involved throughout the life of the project. This is another form of communication that is critical. End users have the kind of input you need to put out the products they need and will use. Keeping them in the loop can save you a lot of wasted time, effort, and money.
Exceed expectations. That may sound contradictory to the earlier advice not to accept extra or unnecessary tasks and not to gold plate requirements, but it's not. Exceeding expectations merely means providing documents and products that are of excellent quality and are better or do more than was called for. Ensuring that all products and documents are understandable and usable is a big part of it. This is also a part of quality management.
QA is a process that is considered a pain in the neck or a hindrance by many managers. That may be true, but a good QA program means better products and fewer problems in the long run. There are excellent QA processes out there. Find and use them.
The same is true of a comprehensive testing program. Adequate and timely testing with good test plans makes for good products and prevents major problems in the field. Don't scrimp on the testing. It will come back to haunt you! The timely aspect is important, too. If at all possible, include independent testers. Finally, have the expected users as a part of testing.
Encourage buy-in at every level. You need the team to have feelings of ownership, and you need support from those up the chain and those who will be the final users. Buy-in can help with your budget and getting the resources that you need. Having a true champion (someone who believes in your project and will fight for it) in the higher levels of the management structure can really ease your way.
The government has thousands of pages of laws, regulations, and guidance for you as a project manager. Be aware that in those thousands of pages there will be contradictions. Compliance with the appropriate ones is a must, and you aren't going to know all of the appropriate ones. That's why there are experts that you can consult. Don't hesitate to call on them. That's their job. Whether it's the lawyers, contracting, or some other organization, ask questions and listen--truly listen--to the answers. Do your own research, too. The experts may not have all the answers.
Keep on Learning
Finally, never stop reading, talking with others, and learning. Project management is complex. No one knows it all or all of the tricks to making a project a success. First learn from others, then share what you have learned.
No two projects are the same. I've tried to provide some principles and processes that will work all the time and others which will help in most projects. The ideas and suggestions are not comprehensive, but basic. This primer is a distillation of some lessons learned that can help make you and your project a success.
As I said in the first article, project management is an art. Between the two articles, you have a wide palette of paints to work with, but none of the paint pots is deep. It will require more work on your part. Project management is tough, but it also can be rewarding.
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. He is a frequent contributor to Defense AT & L.
The author welcomes comments and questions. Contact him at firstname.lastname@example.org.
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||WORKFORCE DEVELOPMENT|
|Publication:||Defense AT & L|
|Date:||Jul 1, 2005|
|Previous Article:||Blurring the line between R & D and operations: the Missile Defense Agency's acquisition approach.|
|Next Article:||10th Annual NAVSUP Academy Focuses on Transformation.|