BUS402: Project Management

Ten Axioms for Success

To help you get started here's ten (self evident) truths:

1. Know your goal
   It sounds obvious but if you don't have an end-point in mind, you'll never get there. You must be able to clearly state the goal of your project so that anyone can understand it. If you can't adequately describe your goal in a single sentence then your chances of achieving it are pretty slim.
   
2. 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.
3. Know your stakeholders
   Spend time with your stakeholders. Stakeholders will either contribute expert knowledge to the project or will 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.
   
4. Spend time on planning and design
   A big mistake traditionally committed on projects is to leap before you're are ready. When you're under pressure to deliver, the temptation is to 'get the ball rolling'. The ball however, is big and heavy and it's very, very difficult to change its direction once it gets moving. You need to spend time deciding exactly how you're going to solve your problem in the most efficient and elegant way.
   
5. 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 things go wrong
     
   • Generate a positive and receptive atmosphere
     
   
   Consider this: if you finish early everyone will be happy; if something goes wrong you might still finish on time and everyone will still be happy; if things goes really badly you might still not deliver what you anticipated but it will still be better than if you over-promised
6. 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. This works but only with close attention to how each piece is analysed and resolved and how the whole fits together. Without a systematic approach you end up with a hundred different solutions instead of one big one.
   
7. Stay on track
   Presumably you have an end goal in mind. Maybe it's your job, maybe your business depends upon it or maybe you're going to revolutionise the world with the next Google, the next World Wide Web or the next Siebel/SAP/Oracle. If this is the case you need to work methodically towards a goal and provide leadership (make decisions). This applies whether you're a senior project manager running a team of 20 or you're a lone web developer. You need to learn to use tools like schedules and budgets to keep on track.
   
8. 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 ratholes 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 allows you to accommodate 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.
   
   The best way to handle this is to have a plan, to update it regularly and make sure everyone is following it and pointing in the same direction.
   
9. Test Early, Test Often
   Project usually involve creative disciplines loaded with assumptions and mistakes. The only way to eliminate errors is through testing. Sure you can do a lot of valuable work to prevent these mistakes being introduced, but to err is human and some of those errors will make it into your finished product code. Testing is the only way to find and eliminate errors.
   
10. Keep an open mind!
    Be flexible! The essential outcome is 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. 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.

In reality 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 in a project and the "Quality" of the end project 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).

A phenomenon known in project management circles 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 probably 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 such a dilemma you should not hesitate to take one of the three options listed above. 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 retrained. A better project manager will make better use of one or more of the axes and will recognise when they need to 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 surely 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 have changed. 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.

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 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". They are no less valid today than they were then, 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 resources 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 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 during the development cycle 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 plan 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.

Scope

You have to know what you are trying to do.

This seems obvious but lack of clarity in the early stages of a project is very common and causes many problems. Many projects start up with vague or ill defined ideas of what they want to achieve. If you hope to deliver a successful project in a finite amount of time you need to determine the final state your product must achieve, you need to set yourself a concrete goal.

If you have an infinite amount of time you could simply try one solution after another until you hit upon the best solution for your problem. This 'inventive' approach to product development can give rise to spectacular and unique solutions but more often than not ends in failure or inadequate results. Also most of us don't operate in environments where we have infinite amounts of time or resources. Most of us operate in an environment where we need to deliver a concrete in solution in a very finite period of time.

In order to do this we need a way to select the best solution from a range of possible approaches. The first and most important step in this process is defining what will actually constitute a success. Then we can evaluate all of the possibilities against our definition of success and find the best fit. Without this we'll be shooting in the dark.

The more disciplined you can be about defining your objectives, the more likely you will be to succeed.

Scope, Visions and Goals

Scope is a general term to describe everything that your project encompasses, everything that must be achieved for the project to be complete. This would encompass your vision, your goals and your requirements and would be embodied in documents such as a "project proposal" and at a lower level "commercial specifications" and "technical specifications".

The word 'vision' produces shudders in technical and non-technical people the world over. And rightly so, for a vision is normally a collection of meaningless catch phrases and marketing dribble intended to dupe people into thinking that businesses are there for some polite and altruistic reason, rather than to extract every last cent out of their customers. This is not the kind of vision I mean.

When I talk about vision I'm simply saying that you need a single encapsulated idea which defines the aim of your project. Why are you doing the project in the first place ? What makes a project a project is the fact that it is a standalone task (or set of tasks) that has an intended outcome. You work on your project, complete it and then move on to the next.

If you can't state the aim of your project in a single sentence, then it's probably not a project.

Maybe it's an idea for a business or possibly a way of life but not a project. It might even be a set of projects that need to be divided into single 'efforts'. A project is a defined task with a finite life with a fixed end point and that end is defined by your 'vision'.

Without a single, linking goal all the dependent steps of project planning become difficult to manage. That single vision may be broken up in sub-goals but it provides the link that holds all of the disparate parts of the project together into a single enterprise. It gives your team and stakeholders a sense of purpose and defines the success of your project.

Goals are slightly lower-level and more specific than the vision. Goals should directly support the overall vision of the project but refine its definition. Typically goals are set out by customers or by a business and define how the success of the project will be achieved. While the vision encompasses the whole project, goals may refer only to the objectives of a particular segment of the project.

Note that the terms scope, vision and goal are largely interchangeable. Different organisations use them in different contexts to refer to much the same concepts. The definitions set out here are the most commonly used versions. Use the version most appropriate to you.

The Vision as Inspiration

While further steps in the project planning aim to be more and more specific the initial goal should be broad enough to encompass the whole project. The vision must state, succinctly, the ultimate goal for the whole project.

The goal or vision should also be inspiring or, appropriately enough, "visionary".

Goals like: "To deliver the cheapest system, in the shortest time, that just about gets the job done" are unlikely to inspire anyone or motivate a team.

On the other hand a goal like: "Deliver the best sales and marketing system on the market" is more likely to inspire personal involvement from team members and stakeholders.

If you are working on your own an inspirational vision can restore your flagging enthusiasm. When the client or your manager calls you up for the nth time and says "Where's that bit of documentation I asked for ?" and you say to yourself "Why am I doing this again ?" – your answer could be "because I'm writing the best damn **insert name** the world is ever going to see!".

Visions don't have to be written down or cast in stone. They don't even have to be formalised in any particular sense. In large organisations they often are since that's the kind of the thing large organisations like to do, but the only important thing is that you, your team and your stakeholders know exactly what the vision is and agree on it.

Don't go overboard, now is not the time to exercise your commercial-buzzword vocabulary. Select language that is natural and easy for you to use and that sounds sincere. The more you believe the vision and the more you use it, the more that other people, including your team and your customers, will come to believe it to and the more chance you will have of succeeding.

Goals as a Filter for Requirements

One of the primary purposes of goals is to act as a filter for subsequent requirements.

If a particular requirement cannot be traced back through higher-level goals to the overall project vision then it should be dropped since it will be outside the scope of the project.

For example, if the overall vision for the project was to "Deliver the best sales and marketing system on the market" an appropriate sub-goal might be "to deliver a sales-order processing system for use throughout all international offices". An inappropriate sub-goal would be "to deliver an invoicing system" since the invoicing system would be part of the financial system and not the sales system.

This process of filtering should be used throughout the life cycle of the project to assess requests for extra functionality and to consider them for inclusion within the project. The use of such filtering techniques gives you an easy method with which to avoid the perils of "scope creep".

The linkage between low and high level goals can be fundamentally important to your team as well. By linking them together you can track your progress through the objectives of your product. By delivering low level goals you build up to the delivery of high level goals and ultimately the delivery of the completed project. This is known as traceability.

A Decent Proposal

Sometimes referred to as a 'business case', the project proposal states the highest level goals in a project. It outlines the overall business goals and vision for the project as decided by the customer or client. It is sometimes drawn up well before the project starts although you may (if you are lucky) also get a hand in its creation.

The basic proposal should contain the vision for the project and the business goals, what your client hopes to achieve at a business level. There may also be a large amount of supporting information in order to qualify or corroborate the stated goals but the goal should be clear. The supporting information might be preliminary forms of the project planning such as budgets, schedules and so forth.

Project proposals are often vital documents because they are what gets signed off when a commercial deal is agreed. As such you need to consider them carefully because they may be define what your are legally committed to delivering.

Source: Nick Jenkins, https://learn.saylor.org/pluginfile.php/5749258/mod_page/content/2/BUS402-1.5-projectPrimer-CCBYNCSA.pdf
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.