What We Liked
Under Book Structure, we noted that the fourth table of contents provides a "Cross Reference of Project Management Processes and Lessons". This is possibly the most useful for anyone who has read the book through as a comfortable and engaging read and then wishes to use it as a learning reference for the TenStep project management process sequence itself.
For a neophyte project manager, like many of those in the stories, or even for a newly-organized project management group, the templates provided on the CD should be a valuable starting point for standardizing key project management documentation.
Some quotations worthy of note
On leveraging knowledge from prior projects and saving knowledge for future projects:
"So much organizational knowledge gets lost over time if no processes are designed to capture and exploit information. This is the essence of knowledge management, which consists of the processes required to collect, organize, retrieve, share, and leverage the knowledge that exists throughout the company. Sometimes this knowledge is organizational in nature, but many times the knowledge is project based, and can be leveraged on subsequent projects."[6]
On work plans:
"Don't 'micro-build' or micromanage the workplan … Generally, there are two rules of thumb when it comes to defining the level of detail in the workplan. First, [it] must be at a level where both the project manager and the project team can understand the work … If a piece of work is well understood, it can be placed on the workplan at a higher level. However, if it is not clear what the nature of the assignment is, then the activity should be broken down into its more basic components (in some companies, these lowest level statements are called tasks.) … The second rule of thumb is that the workplan must include time to react if an activity is in trouble. In general, an activity should never be longer than 80 hours (two weeks) [assuming] a typical six-month project."[7]
On the subject of estimating:
"By its very nature, estimating is a guess. Of course, by using proper
estimating techniques, you can make it a very close guess. However, there is always
some degree of uncertainty in an estimate [so] Don't use your estimating contingency
for scope changes … When you place a contingency in the project, everyone should
understand that it is there to recognize the estimating uncertainty."[8]
"In general, you can estimate work based on one of three scenarios
– worst case, most likely case, and best case. If you give your client an estimate
based on the worst-case scenario, you are not under-promising. You are sandbagging,
which means you are purposely setting very low expectations you know can be exceeded."[9]
"The best-case scenario is just the opposite. If you present the best case you are assuming everything will go according to plan and everything will work great the first time. This is also not a good estimate to present to the client, for the same reason that worst-case numbers are not good. The client cannot make the best business decisions if the project estimates are skewed one way or another."[10]
On the subject of risks, problems and issues:
"An 'issue' arises when a problem will impeded the progress of the
project and cannot be resolved by the project manager and project team without outside
help[11] … In other words, an issue is a
current problem that must be dealt with, whereas a risk is a potential problem that
has not yet occurred[12] … One of [the team's]
primary responsibilities is to raise issues when they see them."[13]
"Issues and risks are related but not the same … By its nature issues management is a reactive project management process [whereas] risk management is a proactive project management process, since you are trying to deal with potential future events."[14]
On managing documents:
"Manage documents properly to avoid confusion and mix-ups. One of the more sophisticated aspects of managing a project is to manage the flow of documentation. Small project teams normally do not need to put a lot of effort into document management. However, sharing of information becomes increasingly complicated, as a project gets larger. Document management tools can help to enforce many of the rules for sharing documents, but most companies still rely on manual processes … The best practice is for project managers to consider the amount of documentation their project will generate before the project starts … [And] for your company to establish some guidelines and templates that can be easily and consistently used by default by all project managers in the organization."[15]
To which we might have added, "And before the whole thing gets out of control and lands in a real mess.
6. Ibid, p52
7. Ibid, pp32-33
8. Ibid, pp81-82
9. Ibid, pp171-172
10. Ibid, p172
11. Ibid, p3
12. Ibid, p5
13. Ibid, p57
14. Ibid, p75
15. Ibid, pp36-37
|
Book
Structure
