You don’t have to be a seasoned project manager to have a negative view of the lessons-learned process. But is it really such a waste of time? New PMs especially should carry out lessons learned as often as they can. Here are some ways to do that...
Control or Be Controlled: Follow this Project Manager on the Path to Certification, Part 4As I continue studying the PMBOK to improve my projects, and to pass the PMP certification exam, my favorite phrase in Chapter 4 occurs in the very first paragraph: "...tradeoffs among competing objectives." On my projects, and probably on yours, too, there are a lot of competing objectives.
Your client wants an enhancement? They might have to give a little on the schedule, or fork over more budget allocation. Your developer discovered her time estimate was short? Can you afford to shorten the testing time to compensate?Everything that happens during your project that was not part of the original design can be defined within the "Integrated Change Control" portion of Chapter 4, "Project Integration Management." The brief description says, "...coordinating changes across the entire project." Please notice it said "coordinating," not "reacting to." You must control and coordinate the inevitable changes, or they will control you.
The most helpful aspect of the PMBOK's layout is the overview figure at the beginning of each chapter on the Knowledge Areas.
For instance, Page 42 included Figure 4-1, "Project Integration Management Overview" including these processes: Project Plan Development, Project Plan Execution and Integrated Change Control. Each of the processes includes the following (and this is the uniform organization that is so helpful): inputs; tools and techniques; and outputs.
Of course, the outputs of one process are the inputs for the next. This uniformity is a great help in studying and using these principles. When you have your copy of the PMBOK, here are the additional pages you might want to flag as a help to understanding, using and studying this information.
Page 8. My first sticky-note is here, on Figure 1-1, showing all nine Knowledge Areas and their processes. (Hint: The first Knowledge Area is called #4 because it begins in Chapter 4. That threw me for a while, but only a little while.)
Page 31. My second flag is here because of Figures 3-1 and 3-3 (3-2 is too much work for me), illustrating the five process groups: Initiating Processes, Planning Processes, Controlling Processes, Executing Processes and Closing Processes.
Page 41. My third sticky-note is here because this is the start of "Section II--The Project Management Knowledge Areas." Once you have read the first three chapters, you shouldn't need to refer back to them much, but you will often refer to the remainder of the book...and it starts right here with Chapter 4.
Details and Resources:
PMBOK: "A Guide to the Project Management Body of Knowledge" available from the Project Management Institute http://www.pmi.org).
Please don't be discouraged. If you have been a project manager for any length of time, you are probably using most of the processes and techniques taught in this valuable book. If you are at all like me, you hate studying something you know you will never use. (Remember chemistry in high school?)
I was thinking about studying for a degree in telecommunications, but after an exhaustive five minutes of research I knew that there was far too much taught that I would never use for the classes to be of interest to me. Project management has no wasted parts, though I have admitted in previous articles how I feel about the math.
Once you have studied Chapter 4, with special attention to the change control processes (you control it, don't let it control you), I will leave you on your own again to study Chapter 5, "Project Scope Management" (ever have nightmares about scope creep? This chapter will help alleviate those!).
Here is one final helpful tidbit from Chapter 4 to help you control change in your projects. When developing your project plan, please don't forget to identify your constraints and assumptions. (This is actually an input to the Project Plan Development process, but it can greatly reduce the number of changes needed during your project.)
A constraint is something that you must do without or work within, such as a predefined budget limitation, or a delivery timeframe that must be met for the project to be viable (such as software for tax law changes that will be useless to your client if you deliver after April 15).
An assumption is just what it sounds like, something we consider to be true. Once you identify these, you might want to reduce your list of assumptions by turning them into known quantities.
To start your list, ask yourself, "What are we assuming about this project?" You might come up with answers like, "We are assuming the client is involving the end-users in their design meetings. We are assuming the system clock will use Greenwich Meantime. We are assuming the testing team will be available when we need them near the end of the project."
This can help you identify weak spots you hadn't previously seen. Most assumptions involve risk, and you can minimize the risk to your project, and the number of changes needed down the road, by controlling as many assumptions as you can.
Add the end users to your project team. Confirm what time stamp the system clock should use. Have a back-up plan ready in case the testing team has not completed its previous project.
(If this is peaking your interest, jump ahead to Chapter 11, "Project Risk Management" for even more help here.)
All of this studying is making me more and more appreciative of the training I have had. More on that next week, as we cover Chapter 6, "Project Time Management."
Donna Boyette is a Project Manager for a large telecommunications company in the
Want more content like this?
Sign up below to access other content on ProjectManagement.com
Already Signed up? Login here.