In summary - you are free: to copy, distribute, display, and perform the work and tomake derivative works. You must attribute the work by directly mentioning the author's name. You may not use this work for commercial purposes and if you alter, transform, or build upon this work, you may distribute the resulting work only under a license identical to this one. For any reuse or distribution, you must make clear to others the license terms of this work. Any of these conditions can be waived if you get permission from the copyright holder. Your fair use and other rights are in no way affected by the above. Please see the license for full details.
43 trang |
Chia sẻ: haohao89 | Lượt xem: 2070 | Lượt tải: 0
Bạn đang xem trước 20 trang tài liệu A project management primer, để xem tài liệu hoàn chỉnh bạn click vào nút DOWNLOAD ở trên
A Project Management
Primer
or “a guide to making projects work (v2.0)”
by Nick Jenkins
©Nick Jenkins, 2006
This work is licensed under the Creative Commons (Attribution-NonCommercial-
ShareAlike) 2.5 License.. To view a copy of this license, visit
[]; or, (b) send a letter to “Creative
Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA”.
In summary - you are free: to copy, distribute, display, and perform the work and to
make derivative works. You must attribute the work by directly mentioning the author's
name. You may not use this work for commercial purposes and if you alter, transform,
or build upon this work, you may distribute the resulting work only under a license
identical to this one. For any reuse or distribution, you must make clear to others the
license terms of this work. Any of these conditions can be waived if you get
permission from the copyright holder. Your fair use and other rights are in no way
affected by the above. Please see the license for full details.
Table of Contents
INTRODUCTION............................................................................................................................... 3
BASIC PRINCIPLES..........................................................................................................................4
Ten Axioms for Success....................................................................................................................4
Scope Triangle...................................................................................................................................6
The Critical Path................................................................................................................................ 7
The Mythical Man Month................................................................................................................... 7
SCOPE ............................................................................................................................................10
Scope, Visions and Goals............................................................................................................... 10
Requirements.................................................................................................................................. 15
Requirements capture..................................................................................................................... 17
Documenting Requirements............................................................................................................19
Traceability...................................................................................................................................... 22
PLANNING.......................................................................................................................................23
The Purpose of a Project Plan........................................................................................................ 23
The Fine Art of Scheduling..............................................................................................................24
Costing and Budgeting.................................................................................................................... 29
Risk Management............................................................................................................................31
Change Management ..................................................................................................................... 33
EXECUTION.................................................................................................................................... 35
Staying on track............................................................................................................................... 35
Managing People.............................................................................................................................36
IMPLEMENTATION.........................................................................................................................39
REVIEW...........................................................................................................................................42
GLOSSARY..................................................................................................................................... 43
A Project Management Primer (©Nick Jenkins 2006) 2 - 43
I n t r o d u c t i o n
Many projects fail because of the simplest of causes.
You don’t have to be a genius to deliver a project on time, nor do you have to be steeped in a
mystical project management methodology to be a project manager. If an averagely competent
person can’t deliver a project successfully after reading this primer then I will run buck naked
through Times Square on my 75th birthday.
See if I don’t!
Nick
That reminds me of a joke…
A tourist walked into a pet shop and was looking at the animals on display. While he was there,
another customer walked in and said to the shopkeeper, "I'll have a C monkey please." The
shopkeeper nodded, went over to a cage at the side of the shop and took out a monkey. He
fitted a collar and leash, handed it to the customer, saying, "That'll be £5,000."
The customer paid and walked out with his monkey.
Startled, the tourist went over to the shopkeeper and said, "That was a very expensive monkey.
Most of them are only a few hundred pounds. Why did it cost so much?" The shopkeeper
answered, "Ah, that monkey can program in C - very fast, tight code, no bugs, well worth the
money."
The tourist looked at a monkey in another cage. "Hey, that one's even more expensive! £10,000!
What does it do?"
"Oh, that one's a C++ monkey; it can manage object-oriented programming, Visual C++, even
some Java. All the really useful stuff," said the shopkeeper.
The tourist looked around for a little longer and saw a third monkey in a cage of its own. The
price tag around its neck read £50,000. The tourist gasped to the shopkeeper, "That one costs
more than all the others put together! What on earth does it do?"
The shopkeeper replied, "Well, I haven't actually seen it do anything, but it says it's a project
manager".
A Project Management Primer (©Nick Jenkins 2006) 3 - 43
B a s i c P r i n c i p l e s
Ten Axioms for Success
To help you get started here’s ten (self evident) truths :
I. Know your goal
It may sound obvious, but if you don’t have an end-point in mind you’ll never get there. You should
be able to clearly state the goal of your project in a single sentence. If you can't, your chance of
achieving it is slim.
II. Know your team
Your team is the most important resource you have available and their enthusiastic contribution will
make or break your project. Look after them and make sure the team operates as a unit and not as
a collection of individuals. Communications are vital! Invest time in promoting trust and ensuring
that everyone knows what they have to contribute to the bigger picture. Dish out reward as well as
criticism, provide superior working conditions and lead by example.
III. Know your stakeholders
Spend time with your stakeholders. Stakeholders either contribute expert knowledge offer their
political or commercial endorsement which will be essential to success. Shake hands and kiss
babies as necessary and grease the wheels of the bureaucratic machine so that your project has
the smoothest ride possible.
IV. Spend time on planning and design
A traditional mistake is to leap before you are ready. When you’re under pressure to deliver, the
temptation is to ‘get the ball rolling’. The ball is big and heavy and it's very, very difficult to change
its direction once it gets moving. So spend some time deciding exactly how you’re going to solve
your problem in the most efficient and elegant way.
V. Promise low and deliver high
Try and deliver happy surprises and not unpleasant ones. By promising low (understating your
goals) and delivering high (delivering more than your promised) you :
• Build confidence in yourself, the project and the team
• Buy yourself contingency in the event that something goes wrong
• Generate a positive and receptive atmosphere
Consider : if everything goes right you will finish early everyone will be happy; if something goes
wrong you might still finish on time ; if things goes really badly you might still not deliver what you
anticipated but it will still be better than if you over-promised!
A Project Management Primer (©Nick Jenkins 2006) 4 - 43
VI. Iterate! Increment! Evolve!
Most problems worth solving are too big to swallow in one lump. Any serious project will require
some kind of decomposition of the problem in order to solve it. You must pay close attention to
how each piece fits the overall solution. Without a systematic approach you end up with a hundred
different solutions instead of one big one.
VII. Stay on track
You have an end goal in mind. You need to work methodically towards the goal and provide
leadership (make decisions). This applies whether you’re a senior project manager with a team of
20 or you’re a lone web developer. Learn to use tools like schedules and budgets to stay on track.
Consistency is what separates professionals from amateurs.
VIII. Manage change
We live in a changing world. As your project progresses the temptation to deviate from the plan will
become irresistible. Stakeholders will come up with new and ‘interesting’ ideas, your team will bolt
down all kinds of rat holes and your original goal will have all the permanence of a snowflake in
quicksand. Scope creep or drift is a major source of project failure and you need to manage or
control changes if you want to succeed.
This doesn’t imply that there should be single, immutable plan which is written down and all other
ideas must be stifled. You need to build a flexible approach that absorbs changes as they arise. It’s
a happy medium you’re striving for - if you are too flexible your project will meander like a horse
without a rider and if you are too rigid your project will shatter like a pane of glass the first time a
stakeholder tosses you a new requirement.
IX. Test Early, Test Often
Projects involve creative disciplines burdened with assumptions and mistakes. Sure you can do a
lot of valuable work to prevent mistakes being introduced, but to err is human and some of errors
will make it into your finished product. Testing is the best way to find and eliminate errors.
X. Keep an open mind!
Be flexible! The desired outcome is the delivery of the finished project to a customer who is
satisfied with the result. Any means necessary can be used to achieve this and every rule listed
above can be broken in the right circumstances, for the right reasons.
Don’t get locked into an ideology if the circumstances dictate otherwise.
Don’t get blinded by methodology.
Follow your head.
Focus on delivering the project and use all the tools and people available to you. Keep an eye on
the schedule and adjust your expectations and your plan to suit the conditions. Deliver the finished
product, promote its use, celebrate your success and then move on to the next project.
A Project Management Primer (©Nick Jenkins 2006) 5 - 43
Scope Triangle
Called the ‘Scope Triangle’ or the ‘Quality Triangle’ this shows
the trade-offs inherent in any project.
The triangle illustrates the relationship between three primary
forces in a project. Time is the available time to deliver the
project, cost represents the amount of money or resources
available and quality represents the “fit-to-purpose” that the
project must achieve to be a success.
The normal situation is that one of these factors is fixed and
the other two will vary in inverse proportion to each other. For
example “Time” is often fixed and the “Quality” of the end
product will depend on the “Cost” or resources available. Similarly if you are working to a fixed level
of “Quality” then the “Cost” of the project will largely be dependent upon the “Time” available (if you
have longer you can do it with fewer people).
The astute reader will be wondering what happens when two of the points are fixed. This is
when it really gets interesting. Normally this occurs when costs are fixed and there is a definite
deadline for delivery, an all too familiar set of circumstances. Then, if the scope starts to creep
you are left with only one choice – cut functionality. This more common than you might think, in
fact its more common than not!
Cutting functionality may seem a drastic measure, but an experienced project manager will
happily whittle away functionality as if they were peeling a potato. As long as the core
requirements remain, everything will be fine. Additional functionality can always go into “the next
release”, but if you don’t deliver the core functionality, there won’t be a next release.
A really experienced project manager might even pad his project with a little superfluous
functionality that could be sacrificed when the crunch comes (but you didn’t hear it from me!).
A phenomenon known as “scope creep” can be linked to the triangle too. Scope creep is the almost
unstoppable tendency a project has to accumulate new functionality. Some scope creep is
inevitable since, early on, your project will be poorly defined and will need to evolve. A large
amount of scope creep however can be disastrous.
When the scope starts to creep, new functionality must be added to cover the increased scope.
This is represented by the quality arm of the triangle, representing the ability of the ‘product’ to fulfil
users’ requirements. More requirements fulfilled = a better quality product.
In this situation you have three, and only three options :
1. Add time – delay the project to give you more time to add the functionality
2. Add cost – recruit, hire or acquire more people to do the extra work
3. Cut quality – trade off some non-essential requirements for the new requirements
If the art of management lies in making decisions, then the art of project management lies in
making decisions quickly! When faced with scope creep you cannot ignore it. You need to tackle it
in one of the ways described above (more later) and the sooner the better. Delaying raises the risk
of your project failing.
A poor project manager will see the scope triangle as a strait-jacket by which their project is
irrevocably constrained. A better project manager will make better use of one or more of the axes
and will shift the emphasis in the project to one of the other axes. The best project managers will
juggle all three like hot potatoes and will make decisions every day which effectively trade-off time
vs quality vs resources.
A Project Management Primer (©Nick Jenkins 2006) 6 - 43
Time
QualityCost
Heat oil in
frying pan
Fry bacon and
sausages
Scramble Eggs
Serve
Wash plates
Make toast
Start breakfast
The Critical Path
Another important concept in planning projects is that of the critical path. If a project consists of a
set of tasks which need to be completed, the critical path represents the minimum such set, the
critical set. This might seem to be a contradiction since you might think completion of all tasks is
necessary to complete a project; after all, if they weren’t necessary they wouldn’t be part of your
project, would they?
The critical path represents not the ideal set of tasks to be complete for your project, but the
minimum set. It is this path that you must traverse in order to reach completion of your project on
time. Other tasks while important to overall completion do not impact upon the final delivery for the
project. They can therefore be rescheduled if time is tight or circumstances change. Tasks on your
critical path however will affect the delivery time of the project and therefore should only be
modified in extremis.
In the following example the critical path is
represented in bold. In order to complete my
project of cooking breakfast I have to go through
the steps of frying bacon and sausages and
scrambling eggs.
The tasks “make toast” and “wash plates”, while
important, are not time-dependent or as critical
as the other three tasks. I can move either of
those tasks but if I try to move anything on the
critical path its going to delay the project.
Ideally I’d like to have toast with my breakfast but
a) it’s not essential and b) it doesn’t matter where
in the process it happens. If I make toast before
or after scrambling my bacon, it makes little
difference to the overall result.
On the other hand I can hardly fry my bacon
before the oil is hot, nor can I scramble my eggs
before frying my bacon (they’d turn to glue).
The critical path represents the critical sequence
of events which must occur if I want to
successfully complete my project.
Normally major 'milestones' will be represented
on the critical path and they will often occur when
different threads of the project come together.
For example in the diagram to the right my only
milestone is when I serve the completed breakfast. At this point I will have finished my preparations
and completed everything on both tracks. This is represented by a diamond in the diagram above.
If I suddenly discovered I was late for work, I could cheerfully discard the optional “toast”
component of my project, take the critical path instead and still achieve my original milestone of
delivering breakfast (and maybe even make it to work on time!).
A Project Management Primer (©Nick Jenkins 2006) 7 - 43
The Mythical Man Month
In 1975 during the pioneering days of software development a man named Frederick Brooks
penned a number of books and articles on the subject. His most famous is “No Silver Bullet”, in
which Brooks pointed out that software development could expect no thunderbolt solution to its
various problems of quality, cost and complexity other than to adopt rigorous methodology.
Only slightly less famous than “No Silver Bullet” is another Brook’s paper, “The Mythical Man
Month”. The papers are no less valid today than they were when written, but they receive a lot less
attention.
In “The Mythical Man Month” Brooks argues that adding people to a project doesn’t speed it up.
While it is true that more resources can speed up the delivery of a software product, the increase in
speed is not directly proportional to the amount of resource added. To put it another way, simply
adding people to your project will not ensure earlier delivery.
The main reason for this is the increased complexity of communications which results from adding
more people. As each person is added to the project team the complexity of communications goes
up exponentially. For each project there is a break-even limit where adding more people will in fact
slow down the project.
People 2 3 4 6 6 (n)
Interfaces 1 3 6 10 15 n
2 –n
2
The diagram above demonstrates the principle graphically. Note that you need not consider each
of the ‘nodes’ in the graph to be an individual person – they could be a group of people or an
organisation within the project that has an 'interface'. The more interfaces you add the more
complexity you add to communication and the more overhead you add to the project.
If you don’t believe the math, look at it logically. Every additional person brought into a project will
need to be trained and briefed on the current status and assigned tasks. As more and more people
are added, more of the original team must be devoted to managing the overall structure. This is a
truism of all