Home Project Management General Practical Project Management A Guide on How to make Projects Work : Part 4
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 4 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... We continue the serialisation of A Project Management Primer by our intrepid traveller Nick Jenkins (c) 2005  http://www.nickjenkins.net

 E x e c u t i o n

Staying on track

The single biggest problem for a project during the execution phase of the project is staying on track. Despite all the best planning, having the best team and anticipating all the possible pitfalls projects have a knack of developing unforeseen problems.

The Myth of Completion

There is a common falsehood about tasks which is promoted by project tools such as Microsoft Project. The myth is that tasks can be partially complete, i.e. a task can be 10% or 20% done.

If a task is thought of as a goal then the lie becomes obvious – either you have achieved your goal or you have not. It’s a black-and-white, binary proposition. If your goal is a vague and imprecise statement of intent, like “write some instructional documentation”, then it is complete the moment you start. As soon as you put pen to paper you have “written some instructional documentation”.

On the other hand if the task is well defined and has a measurable deliverable then the goal is not achieved until it is delivered. For example: “complete a user guide and a technical manual”. This task definition is much more useful because it has a clear measure of success. The only time the task is complete is when the documents are written, have been reviewed and edited and are ready for publication. You are finished when there are no more changes to be made.

The danger in believing that tasks can be partially completed is that it gives you a false sense of security. Because 50% of a task can be such a hard thing to define, people will tell you they have completed 50% of the task when they are 50% of the way through the time allocated to it. It might be the case that 90% of the task remains but they will insist that since there is 50% of the time left there must be only half of the work left, too.

This misconception is particular entertained by those people who believe that time is elastic. That is that you can cram any amount of work into a particular length of time, it just depends on how hard you work.

These are the people that will tell you one of two things:

1. After working 10 days on a 20-day task they announce that they have only done 10% (i.e. nothing but 10% sounds better) and that they will make up the time. This is despite the fact that they fought tooth-and-nail in the first place to get 20 days allocated to the task. Truth be told they are simply rolling their delays from one task into the next and picking up speed as they accelerate through the project towards non-delivery.

2. The second case is that they report good progress all the way through the first 15 days of a 20 day task and then their progress slows down so that on successive days they go from 95% complete to 96%. They will certainly overrun their task and be claiming three weeks later that the last 1% of the task is nearly done. The old adage of the “first half of a task takes 90% of the time and the other half of the task takes the remaining 90% of the time” is all too often true.

It is much better to break tasks down into smaller steps and to simply report on their completion.
Then if a particular task misses its completion date it automatically triggers an adjustment to the schedule. There is no ambiguity, there is no confusion.

Managing People

It is not often recognised that a project manager must be a people manager as well. Often project managers come from a particular technical stream and they find themselves elevated to a leadership position without any formalised management training. Their first project may confront them with their first test in team leadership.

Most project managers therefore excel at the technical aspects of project management such as scheduling, design and testing. Many, however, are weak or uncomfortable with the core management disciplines which deal with ‘soft skills’. This section will give an overview of some important people skills for the project manager.


Negotiation can be a tricky business for technical people, we tend to see the world as a black-andwhite environment. ‘Techies’ often believe that there is a right and wrong way to solve a problem, or that one technology or solution is the ‘best’ available. This is part of their drive for perfection but in truth there are many ways to solve a problem and each technology or solution has its strength and weaknesses.

Negotiation is the process of achieving consensus while avoiding conflict. Central to this is the understanding that the best solution to a problem is one which attracts the consensus of all those involved. A unilateral (binary) solution is by definition not the best solution since it alienates or disappoints someone. Finding the best solution will involve compromises and the project manager will be the fulcrum around around which the discussions between different parties revolve.

Most people view discussions as a zero-sum-game. That is, in order to “win” or succeed, someone must “lose”. For example a salesman might believe that he will “win” if he can convince someone to buy a product at a high price. This is a zero-sum attitude, the salesman has “won” and the customer has “lost”. A customer on the other hand might not care about the price and might be willing to pay if the product has the right features. If the salesman can work out what the customer wants he might be able to sell him the right product. Further if a particular product doesn't have those features, the salesman might be able to drop the price or offer other incentives that will convince the customer to buy. If he achieves this then they both win.

This is the art of negotiation

Problems can be broken down into a number of elements which, when handled separately, produce trade-offs by which you can achieve a “win/win” solution. This is a solution where both parties walk away happy. This avoids the dichotomy of a binary, yes-no problem and the situation where both parties hold equally strong views, resulting in conflict.

This requires a leap of faith. If you approach discussions with the idea that negotiation is some tricky way to beat people and get your own way, you will certainly fail. People are not stupid and most will be able to discern your intent regardless of your outward demeanour.
Negotiation must be undertaken from a basis of trust and if people feel you can’t be trusted then it doesn’t matter how clever your approach. Try it out for yourself. Approach a discussion with an open attitude and work through to a consensus. Afterwards evaluate how you feel about the solution; you may be surprised. If not, get a job as a used car salesman.

Elements of Negotiation

Understanding is fundamental to negotiation. You must understand the proposal under discussion and the options available. You must understand what each party involved in the discussions seeks to gain from the discussion. If the discussion is composed of groups of individuals you should understand the goals of the individuals and the goals of the groups (which may differ).

You must also understand what you bring to the table and what you are prepared to concede. By knowing what you have to ‘trade’ you can enter the discussion with an open mind and flexibility.
Ideally you should know this before you enter negotiations but sometimes this isn't possible.

Empathy is understanding the emotions of those involved. Emotion can cloud communication or it can enhance it but it cannot be excluded. As human beings we react to things on an instinctive emotional level and, like it or not, this dictates much of our reactions. By understanding the basic feelings of individuals in a negotiation it is possible for you to appeal to them on a more direct level than simple logic.

Successful negotiations are built on trust. Without trust there can be no true compromise and therefore no solution. If the concessions you offer are insincere or grudging, then you will get an equally grudging response from other parties involved. Often it is the responsibility of the project manager, who holds a pivotal position, to take the lead by establishing a basis of trust between the parties involved. By setting the standards a project manager establishes the basis for negotiations and the tone in which they are conducted. This can often be done by a simple appraisal of the facts and an appeal for assistance to the parties involved. Something like “I understand we have a problem and I expect everyone here to contribute to the solution” often works wonders.

Once the fundamentals have been dealt with, a discussion of the problem usually ensues. The discussion should be conducted on a rational basis avoiding violent emotions. The problem should be clearly stated and agreed upon and solutions offered. During this stage of the discussion it is essential that all parties contribute. Silence is not acceptable. Comments should be sought from everyone, their concerns aired, addressed and hopefully resolved. Failure to do so will leave one or more parties feeling disenfranchised or disenchanted.

Once the various solutions have been discussed a possible solution can be proposed and if it is acceptable to all, taken forward. If not, some form of compromise must be hammered out and each party must be ready to conceding elements of their requirements in order to find a solution. Each party must then signify their willingness to accept the compromise and move forward.

Rolling over and sticking your feet in the air to have your tummy tickled does NOT constitute a win-win situation ! Don’t enter into negotiations with the expectation that you will have to make all the concessions to reach a consensus. This will leave you feeling vulnerable and powerless.
This is known as a “win-lose” outcome.
You should enter into the negotiation with the expectation that everyone present will be able to give-and-take on their respective issues and work with them to achieve a suitable outcome. You should set your own minimum level of expectations and not be satisfied with the process until you have achieved it.

Building a team

Wince if you must at the title of this section, but one of the most important facets of project management is “team building”. Rather than the fatuous team building games you often encounter at company days, I am referring to some more subtle people management skills.
Trust – Be Open and Honest

Projects, like offices, can often be secretive places with various levels of disclosure due to commercial or political pressures. However the project grapevine works just as fast as the office kind and you can be assured that if you are keeping someone in the dark or deceiving them, you will be on the short end of office gossip faster than you can say “voluntary redundancy”.

Be as open and honest with your team mates as you can. Answer their questions directly and act as a conduit of information for them, not a barrier. If you feel you cannot divulge something, say so.
Your team will appreciate your honestly and reciprocate by relaying information and producing honest and accurate estimates for you.

Equality – Be fair and even handed
One of the maxims I have lived with as a manager is “individuals can succeed but only the team can fail”. Essentially this means that in public you should dish out credit wherever it is due but never criticism. Being criticised in public, in front of your peers, is not a motivating force for anyone.

If there is a project issue that needs to be addressed you can normally broach it as a subject for the whole team to address. By sharing the burden for issues, most teams pull together to solve the problem. By landing it on the shoulders of one or more individuals you often split the team and cause conflict. Open discussion of the problem will encourage the team to take ownership for the problem and solve it themselves.

Loyalty – Protect your team
You will have a split responsibility - on the one hand you have a duty to your client to see the project succeeds - on the other you have a responsibility to represent your team and to support each other. Usually these two aims should be neatly aligned – but not always!

In a situation where you have to choose between the two you need to take the difficult moral stance. Don't air your dirty laundry with the client. Discuss the situation with your team mates and come up with a solution, present this to the client instead.

Learn to delegate
The joke in armed forces often runs that the only order an officer ever need issue is “Carry on Sergeant Major!” Officers are expected to lead and leave the actual getting of things done to those more suited to the task, the troops. If you are dividing up work make sure you delegate properly.

Proper delegation entails laying out the task so someone understand its, so that it has reasonable and achievable goals and so that you give them all the support they require to get the job done.

It also entails giving them enough room to get the task done on their own. If you leave the execution of tasks to them they will, in return, leave you alone to get on with your job. If you spend you time looking over their shoulders it will only annoy them and waste your valuable time.

I m p l e m e n t a t i o n

Hang on a minute, you’re not finished yet!

Okay, the project’s ready, development has finished and it's been thoroughly tested. But you still have to roll it out to a client who’s going to use it in anger. This is the heart-in-the-mouth time when all your hard work is really put to the test.

Prior to launch you have a (relatively short) period to ensure that everything is ready to go and the your project is in a fit state to be released. Leading up to the launch you’ll want to do some final testing and plan the release of the product into the live environment where it is to be used. A strong methodical process is important at this point so that you avoid any last minute hitches.

Acceptance Testing

Acceptance testing forms an important and separate phase from previous testing efforts. Unlike the functional or technical testing, acceptance testing focuses purely on the “acceptance” of the product. Do the clients want it ? This is the pay-off in a commercial project, where the cheques are signed and the money changes hands.

If you have a formalised project you should probably define some acceptance tests earlier in the project, probably in the design phase and signed them off with your client. You can look at your (SMART) requirements and establish a set of tests from them that will prove your product fulfils its goals. This could be as simple as a check list or as complicated as you like.

Release Control

When you release a product ‘into the wild’ you will need to know what you released, to whom and when. This may seem trivial but you'll want to keep track of things so you can make fixes and changes as the customer discovers problems (and they will!).

These are the things you typically need to track for each release :

• The version number or identifier of the release
• The date and time of the release
• The purpose of the release (maintenance, bug fix, testing etc)
• For each component within the release
• the name and version number of the component
• the date it was last modified

Here is an example :


Positive Perception

Most technical people are poor at the public relations side of business. Communications and marketing is generally not our strong point. But no matter how much we might like to think differently, people base decisions upon perceptions. Your project needs to create a positive perception as much as it needs to create a positive result.

To this end you need to capitalise on the successful delivery of your project and put together a “golive” launch that suitably dazzles your intended audience. This might not be a black tie event with flowing champagne and a marching band, but there should be some event that punctuates the launch of your project. This is also a good way to reward your project team and underscore your appreciation for all the hard work. At the very, very least you should launch your project with a general announcement like an email to all the stakeholders.

Finally remember that launches take time and organisation and remember to plan and schedule them appropriately (with lots of contingency!). Since a launch will necessarily be a fixed date with lots of publicity it can be highly embarrassing if you miss that date or are forced to delay it. Early on in the project you can assign a vague date to the launch and then once you have completed your final testing and you are feeling confident you can announce a specific launch date.

Don’t forget to have part or all of your team present during the launch process. This has two important benefits. First and foremost it gives them the recognition they deserve for all their hard work. Sure, you did your part, but the last thing you want to do is sit in your ivory tower claiming all the credit. Secondly it can be fabulous mileage for your PR campaign. To be honest, people would much rather talk to the individuals who slogged through the mud and got the project there by the sweat of their own brows than talk to management!

Maintenance and Upgrades

If your project has any permanency whatsoever it will require maintenance and possible upgrades.
While you will have done your level best to provide for all the users’ requirements, those requirements will evolve over time and your product must evolve with them.

An important part of the maintainability is to make your project, design documentation and supporting material available as an important reference for those that follow in your footsteps. If they are to successfully implement changes within your system to cope with the future needs of users they must understand your thinking.

Scheduling Upgrades

Upgrades are always necessary. You can either ignore them or plan for them ahead of time. If you acknowledge an upgrade or maintenance release will be necessary then you can plan one, say three months from the initial launch of your project.

This will prevent a hiatus in your project team since members can move from working on the initial launch to designing and specifying the next release of the product. They can start to ‘triage’ the defects that have been left from the previous release and decide which will be fixed in the maintenance release and which will not be.

Extending the idea further, if you are working in an environment where you will have continuous releases (rather than a one-off product release) you should contemplate scheduling regular point releases of the product. For example if your are developing a product that will have a major release every year you should consider scheduling a minor release every six months, or possibly every three months, for maintenance. A regular release schedule helps your team, customers and support personnel anticipate releases and plan for them.


Simply dumping your product or system on an unprepared support team will not be appreciated.
The people who are to support your finalised project need to be trained and prepared to do their job properly. As usual the scale of this training will vary with the scale of your project.

At the bottom end of the scale, provision of user manuals and support manuals will be adequate. If your product or system is not very complicated then that may be sufficient. More complicated products might require specific training guides and support material, such as tutorials or simulations to get the support team up to speed. At the top end of the training rung you might want to consider full blown training presentations and accreditation for support analysts.

Also consider using members of your project team to train support analysts. No one will know the product as well as the people who worked on it and some of these people will probably operate as third level support for the system once it has rolled out. By opening up these sources of information to the support teams you will gain their appreciation and support and your project team may actually enjoy getting to interact with the people that will be directly using the product.

R e v i e w

Project management can be a difficult and thankless task. When things go wrong you shoulder the blame and take responsibility. When things go right the credit goes to the team and rarely do you get singled out for a pat on the back.

Yet projects come with astounding rewards. Astute business managers know that it is not the cleverest technical specialist or the smoothest talking salesman who adds real value to a business. It’s the people that can get things done. People who consistently deliver soon gains a reputation for solving problems and will be rewarded accordingly.

Having said that, getting things done is not always easy. Politics, resource limitations, technical problems, personal differences and organisational obstructions can all hamper your attempts to succeed.

The ideas in this book are not a new proprietary model nor a mystical insight into project management. They are merely an observation on how things actually work. It is drawn from realworld involvement in projects and a genuine frustration with existing methodologies.

Using the ideas in this book you should be able to plan, control and execute any project. It is a model that should be easy for the whole team to understand and, with a bit of luck, will allow you to deliver your project on time, on target and under budget.

Best of luck,
Nick Jenkins.

G l o s s a r y


 Acceptance Test  Final functional testing used to evaluate the state of a product and determine its
readiness for the end-user. A ‘gateway’ or ‘milestone’ which must be passed.
 Acceptance Criteria  The criteria by which a product or system is judged at Acceptance Test. Usually derived
from commercial or other requirements.
 Alpha  The first version of product where all of the intended functionality has been
implemented but interface has not been completed and bugs have not been fixed.
 Baseline  A snapshot at a particular point in time of part of a project plan. A “schedule baseline” is
a snapshot of the schedule at that point in time. Can be compared over time.
 Beta  The first version of a product where all of the functionality has been implemented and
the interface is complete but the product still has problems or defects.
 Big-Bang  The implementation of a new system “all at once”, differs from incremental in that the
transition from old to new is (effectively) instantaneous
 Black Box Testing  Testing a product without knowledge of its internal working. Performance is then
compared to expected results to verify the operation of the product.
 Bottom Up  Building or designing a product from elementary building blocks, starting with the
smaller elements and evolving into a lager structure. See “Top Down” for contrast.
 Critical Path  The minimum set of tasks which must be completed to conclude a phase or a project.
 Deliverable  A tangible, physical thing which must be “delivered” or completed at a milestone. The
term is used to imply a tactile end-product amongst all the smoke and noise.
 End-user  The poor sap that gets your product when you’re finished with it! The people that will
actually use your product once it has been developed and implemented.
 Feature/Scope creep  The relentless tendency of a project to self-inflate and take on more features or
functionality than was originally intended. Also known as ‘scope creep’.
 Incremental development  The development or a product in a piece-by-piece fashion, allowing a gradual
implementation of functionality without having the whole thing finished.
 Milestone  A significant point in a project schedule which denotes the delivery of a significant
portion of the project. Normally associated with a particular “deliverable”.
 Prototype  A simple model of a product which is used to resolve a design decision in the project.
 Quality Assurance (QA)  The process of preventing defects from entering a product through best practice. Not
be confused with testing which is done to remove defects already present.
 Requirement  A statement of need from a project stakeholder which identifies a required attribute of
the system or product to be delivered
 ROI “Return On Investment”  A ratio which compares the monetary outlay for a project to
the monetary benefit. Used to show success of a project.
 Show Stopper  A defect that is so serious it literally stops everything. Normally given priority attention
until it is resolved. Also known as “critical” issues.
 Stakeholder  A representative from the client business or end-user base who has a vested interest in
the success of the project and its design
 Testing  The process of critically evaluating a product to find flaws and to determine its current state of readiness for release
 Top Down  Building or designing a product by constructing a high level structure and then filling in gaps in that structure. See “Bottom Up” for contrast
 Usability  The intrinsic quality of a product which makes it simple to use and easy to understand and operate. Often described as the ability of a product to not annoy the user.
 White/Glass Box Testing  Testing Testing a product with an understanding of how it works. See Black Box Testing.



 The End



End of 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.