Home Project Management General Practical Project Management A Guide on How to make Projects Work : Part 1
US FTC Compliance
Yes, all these ads are some kind of affiliate link and I get paid a commission if you click or buy.
Not enough to quit my day job, but it keeps the site alive.
- Jeb Riordan, Editor, PROJECTmagazine
A Guide on How to make Projects Work : Part 1 Print

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 then I will run buck naked throughTimes Square on my 75th birthday. See if I don’t!

A serialisation of A Project Management Primer by Nick Jenkins (c) 2005   http://www.nickjenkins.net 


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!

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.

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 othercost,time,quality 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.

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.

cost, time, qualityThe 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!).

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.



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 types of management, not just project management.

Yet, while obvious, this mistake is committed time and time again by project managers. The first reaction to any slow-down in the schedule or a threat to the delivery of the project is to throw more people at it. This rarely works in a well-controlled project and never in a badly controlled project.

Adding more people to a project requires ‘bandwidth’ to manage them and can distract you from more important goals at hand.

There are a few things to learn from Brook's “Mythical Man Month” :

1. Small autonomous teams are more efficient than large bureaucratic ones, so divide your project up into manageable chunks and let each group work within some kind of defined boundary.

2. If you want to add people to a project, you had better plan carefully how those people are introduced into the team, there will be a lag before they become productive and even be a drain on the productivity of other members of the team. Look for ‘flat spots’ in the schedule to introduce these people to the team.

3. One of your options in the “scope triangle” has just been reduced! If the scope of your project expands you know there’s only a limited benefit in adding more people to the project because of the overheads involved. We’re back to those same two options again : ask for more time; or cut functionality!

One particular project I was involved with illustrated to me the truth behind the “mythical man month” more than any other.
I was the consultant test manager representing the client, a major bank. A senior manager in the bank had staked his reputation on the success of this system and now no expense was spared to make the project fly! The developer, one of the world’s largest IT service companies, had flown in a design team from overseas since no local talent was available at short notice. They had also flown in a top notch project manager from the other side of the world to babysit their first project with the bank.

As the project progressed the plans became more and more ambitious and more and more people were added to the project. We started off with one design team and ended up with three, none of which ever received the same brief. The developer started flying in software engineers from a neighbouring country and then flying them home for the weekend. Local staff were diverted to the project to help the interlopers try and meet their deadlines but they were still reporting to their original line managers.

It was chaos. Developers were sitting around waiting for instructions. Graphic designers were busily designing interfaces for screens whose business logic hadn’t even been finalised. There were at least three different versions of the specifications floating around and no one knew which one was current.

Our role was to vet the quality of the supplied system for the bank, in effect accepting the system on their behalf. We had a field day! Every release was turned back with major bugs because it hadn’t been tested by the developers and was handed over incomplete.

To my knowledge the system was never launched even after our involvement ended.
Expenditure on the whole project must have been on the order of tens of millions of dollars and the project ended up on the scrap heap!



End of Part 1 of A Project Management Primer

Nick Jenkins (c) 2005



About the Author:

Nick Jenkins is an IT manager with experience in software development, testing and project management. He started his working life as a software developer in Perth, Australia, where he helped author a book about educational software. He had is first management role Sydney where he helped establish the Access Testing Centre (ATC). Since then he has has worked in London, Boston and Sydney for companies like the address management specialist QAS Ltd, enterprise security firm ISS Inc. and the telco giant Singtel-Optus. Now he is living and working Prague in the Czech Republic where he is trying to learn how to speak Czech, drink slivovice (plum brandy) and ice skate.

Go to Part 1
Go to Part 2
Go to Part 4
Go to Part 4  

Comments (0)Add Comment

Write comment
bold italicize underline strike url image quote Smile Wink Laugh Grin Angry Sad Shocked Cool Tongue Kiss Cry
smaller | bigger

Copyright © PROJECTmagazine (c) 1998 - 2019 for practical project management information. All rights reserved.