RISK PROFILES & RESOLUTION : RISK MANAGEMENT IN A PROJECT

Risk Profiles

Risk to a project can be measured on two major axes: Likelihood of failure and Impact of failure

The more likely a problem is to occur, the more risk it poses to the project. Even fairly minor problems or issues can become a threat to the project if they occur so frequently that they can’t be avoided. Similarly, the impact or consequences of a problem are also important. Some problems can stop a project in its tracks all by themselves.

Many systems exist for categorizing risks into different categories but the one presented here is fairly simple. In this system each risk item is qualified on two scales: likelihood and impact. 

Each scale is divided into two simple categories of “ Low ” or “ High ” and risks are rated according to each scale.

A. “ Critical ” issue represents one that will stop the project in its tracks (known as a “Show Stopper”) and must be dealt with immediately. 

B. “ Major ” risks represent a significant threat to the project because of their frequency or because of the seriousness of their impact; these threats usually have to be dealt with as soon as possible. 

C. “ Minor ” risks which are neither likely nor particularly serious and can be left until others have been dealt with. Minor risks however have an annoying habit of turning into major ones when your back is turned.

Resolution of risks

Once you have profiled your risk they can be ranked into an ordered list representing the various threats to the project to be dealt with. The more significant can then be examined and assigned an action by the project team.

Typical actions are as below

Research : The risk is not yet fully understood. Its impact or likelihood of occurrence may be unclear or the context in which it may occur could seem unreasonable. Further research by members of the project team is
warranted.

Accept : The risk is unavoidable and must be accepted as-is. This category of risks become extremely important to a project since they cannot be resolved but still represent a threat to completion. Anticipation therefore become the key to dealing with this category of risk.

Reduce : The risk as it stands is unacceptable. The project team must act to reduce the risk and to establish contingency plans should the risk occur. The risk will have to reviewed in future to define the threat it poses.

Eliminate : The risk is unacceptable under any circumstances and must be eliminated as a possibility. The project team must put in place processes and procedures not only to ensure the immediate threat is eliminated but that it does not re-occur in the future.

COSTING & BUDGETING OF A PROJECT

COSTING & BUDGETING OF A PROJECT

Some projects are relatively straightforward to cost but most are not. Even simple figures like the cost per man/hour of labor can be incredibly difficult to calculate and in most cases approximations are used. Some fundamental principles to keep in mind are derived from standing accounting practice as below:

The Concept of 'Prudence'  - You should be pessimistic in your accounts (“Anticipate No Profit and provide for all possible losses”). Provide yourself with a margin for error and not just show the best possible financial position. It’s the old maxim: promise low-deliver / high once again.

The 'Accruals' Concept     - Revenue and costs are accrued or matched with one another and are attributed to the same point in the schedule. For example if the costs of hardware are in your budget at the point where you pay the invoice, then ALL the costs for hardware should be “Accrued” when the invoice is received.

The ‘Consistency’ Concept - This is similar to accruals but it emphasizes consistency over different periods. If you change the basis on which you count certain costs you either need to revise all previous finance accounts in line with this or annotate the change appropriately so people can make comparisons on a like-for-like basis.

Costing

At a basic level the process of costing is reasonably simple. You draw up a list of all your possible expenditure and put a numerical value against each item; the total therefore represents the Tangible Cost of your project.

Tangible Costs

Capital Expenditure - Any large asset of the project which is purchased outright. This usually includes plant, hardware, software and sometimes buildings although these can be accounted for in a number of ways

Lease Costs - Some assets are not purchased outright but are leased to spread the cost over the life of the project. These should be accounted for separately to capital expenditure since the project or company does not own these assets

Staff costs  - All costs for staff must be accounted for and this includes (but is not limited to): Salary and Pension (superannuation) costs; insurance costs; recruitment costs; anything which can be tied directly to employing, training and retaining staff

Professional services  - All large-scale projects require the input of one or more professional groups such as lawyers or accountants. These are normally accounted for separately since a close watch needs to be kept upon expenditure in this area. Without scrutiny the costs of a consultant engineer, accountant or lawyer can quickly dwarf other costs

Supplies and Consumables  - Regular expenditure on supplies is often best covered by a single item in your budget under which these figures are accrued. 

One-off costs - One-off costs apply to expenditure which is not related to any of the above categories but occurs on an irregular basis. Staff training might be an example. While it might be appropriate to list this under staff costs you might wish to track it independently as an irregular cost. The choice is yours but the principles of prudence and consistency apply.

Overheads – Sometime called indirect costs, these are costs which are not directly attributable to any of the above categories but never-the-less impact upon your budget. For example it may not be appropriate to reflect the phone bill for your project in staff costs, yet this still has to be paid and accounted for. Costing for overheads is usually done as a rough percentage of one of the other factors such as “staff costs”.

Intangible Costs

It has become fashionable to account for “Intangible” assets on the balance sheets of companies and possibly also projects. The argument goes like this: some contributions to a project are extremely valuable but cannot necessarily have a tangible value associated with them. 

Typical things you might place in the budget under intangibles are “Goodwill” and “Intellectual Property”. Personnel-related figures are a frequent source of intangible assets and so you might find things like “Management Team”, “Relationships” & “Contacts” on an intangibles balance sheet.

Budgeting

Once you have costed your project you can then prepare an appropriate budget to secure the requisite funds and plan your Cash Flow over the life of the project. An accurate cost model will of course entail a fairly detailed design or at the very least requirement specification so that you can determine your scope of work. This is normally completed well into the design phase of the project.

The sad truth of the matter however is that more often than not you are required to prepare some sort of indicative budget before approval of the project and you are often held to your original estimates. You must be extremely careful with initial estimates and always follow the “Promise Low / Deliver High” commandment.

Costing and Budgeting follow the Iterative life cycle as do other tasks within the project. As you refine your design, so you will need to refine the costing which is based upon it. As in scheduling, you need to build in adequate contingency (reserves) to account for unexpected expenditure. For example, if due to a failure in the critical path a task is delayed and a milestone (like software purchase) falls due in the month after it was scheduled. This can wreck your carefully planned cash flow. But if you have carefully budgeted your project then variations should be relatively easy to spot and cope with as they arise. 

PRINCIPLES OF PROJECT SCHEDULING

In truth the art of scheduling a Project is based on experience and the more experience you have, the more

accurate your schedule will be.

However, by following some simple rules you can still produce an accurate schedule.

Rule #1 - Don't commit to something you can’t Deliver

Scheduling is one part prediction and one part expectation management. If you are pressured into picking a date “on-the-fly” at a random meeting you can bet that the date will not only be wrong, it will come back to haunt you. 

Rule #2 - Eliminate uncertainty wherever you can

The more specific you can be in your project planning, the more accurate your schedule will be. If you leave  functionality or other items unspecified in your plan, then you will, at best, only be able to approximate them in the schedule. Don’t go overboard, though, there is a balance. If you are spending time adding detail to tasks which will have no impact on the project delivery date, then you are probably wasting your time.

Rule #3 - Build in plenty of contingency to cope with variation

No matter how well specified your project and how accurate your schedule, there will be the inevitable random influences that will wreck your carefully crafted schedule. People get sick, equipment fails and external factors join together in a conspiracy to see that you miss your target date. In order to buy yourself some insurance you should build in an adequate amount of contingency, so that you can cope with unexpected delays.

Rule #4 - Pick the right level of granularity

When drawing up your schedule it is important to pick the right level of detail. If you are going to require daily updates from your team then it makes sense to break into day-by-day chunks. That way everybody has the same understanding of what must be achieved by when. 

On the other hand if your project has large portions of time devoted to similar activities, testing for example, then it may be better to simply block-schedule one or two months of testing. Maybe you can leave the details up to your team, it all depends on the level of control you want.

Rule #5 - Schedule for the unexpected

Project management is the art of handling the unknown. 

Often events and circumstances you could not have foreseen will interrupt the flow of your project. It’s your job to take them all in your stride. Schedule for the most likely delays and cope with them should they arise. If experience or instinct tells you that a certain type of task will overrun, then anticipate it, pad it with some

contingency and make sure you have adequate resources on hand when it comes up.

THE PURPOSE AND ELEMENTS OF PROJECT PLAN

The purpose of a project plan is to maintain control of a project.

As a complicated process, a project always threatens to exceed the limit of your control. To maintain control you need help in the form of tools, your best tool is your plan.

The project plan controls the project by:

• Breaking a complex process down into a number of simpler components

• Providing visibility for obscure or ambiguous tasks in the project

• Providing a single point of reference for everyone

• Enforcing scrutiny of the sequence and nature of events

• Providing a baseline against which the actual execution of the project can be compared

• Anticipating likely events and providing pre-planned means of avoiding them

A project plan must be as accurate, complete and as specific as possible. How accurate, complete

and specific of course depends upon how much time and resource you have available.

The Elements of a Project Plan

Every project planning methodology has its own specific taxonomy and names for its parts. But in a very broad sense the minimum elements a project plan must specify are:

What is to be done – what is desired of the project and what it must deliver to succeed. This is a scope document at a high level and requirements specs. at lower levels 

When it needs to be done by– the deadlines by which the objectives must be met

Who is to do it – The people, sometimes unkindly labelled “resources”, or the team who are to deliver those objectives. This also usually implies costs since in most projects the application of costs implies the use of skilled employee

How it is to be achieved – This is normally in documents such as a technical specification 

You do not need to complete all of these prior to starting your project. Typically one draft of the proposal, schedule and budget are completed before your project commences. Each of the other documents will be completed at some point through the life cycle.

SMART REQUIREMENT IN PROJECT

SMART requirements

One useful acronym for defining requirements is SMART :

Specific : A goal or requirement must be specific. It should be worded in definite terms that do not offer any ambiguity in interpretation. It should also be concise and avoid extraneous information.

Measurable : A requirement must have a measurable outcome, otherwise you will not be able to determine when you have delivered it.

Achievable : A requirement or task should be achievable, there is no point in setting requirements that cannot realistically be achieved.

Relevant: Requirements specifications often contain more information than is strictly necessary which complicates documentation. Be concise and coherent.

Time Bound: In order to be of value requirements must be completed within a defined time frame. As well as T stands for testable. You must be able to prove that the requirement has been satisfied. Requirements which are not testable can leave the project in limbo with no proof of delivery.

FUNCTIONAL & NON-FUNCTIONAL REQUIREMENTS OF PROJECT

Requirements specification is the process of refining the goals of a project to decide what must be achieved to satisfy the clients.

Functional Requirements

Functional requirements are the obvious day-to-day requirements end-users and stakeholders will have for the product. They revolve around the functionality that must be present in the project for it to be of use to them.

A functional requirement typically states as “The system X must perform function Y”. This is known as an ‘assertion’. An assertion asserts or affirms a necessary or desirable behavior for the system or product in the eyes of a stakeholder. Without clear assertions requirements are nothing more than vague discussions which have a regrettable tendency to clutter up your desk and your mind.

Some more ‘better’ statements of requirements:

• A customer account record must contain a unique account reference, a primary contact name, contact details and a list of all sales to the customer within the past sales year
• Contact details must consist of a phone number, an address and an optional email address
• For each contact up to five separate phone numbers should be catered for

Non-Functional Requirements

It is essential to consider the other requirements too, these are called “non-functional requirements” which, to my mind, is a bit of an oxymoron. 

1. Performance : Performance usually covers areas such as responsiveness, throughput and speed of operation. What is the minimum performance that will satisfy your client ?

2. Usability : How “easy-to-use” will the finished product be ? For example do you cater for disabled or handicapped users ? Generic ease of use should be considered though, more than one product has failed by supplying full functionality with an obscure or convoluted interface.

3. Reliability : Reliability requirements deal with the continuous availability of the product to users. They should state what availability is necessary and desirable.

4. Security : In products which deal with confidential or sensitive information, security considerations should be taken into account. Requirements for different levels of access, encryption and protection should be gathered.

5. Financial : There may be financial considerations which will determine the success or failure of the project. For example a bank or investor might specify certain financial constraints or covenants which must be satisfied during the project.

6. Legal :  There may be legal requirements that must be met due to the environment in which your product will operate. Consult a legal expert for these.

7. Operational : There may be a number of day-to-day operational issues that need to be considered. Failure to accommodate these will not delay project launch but may limit or halt its uptake by end-users once it has been launched.

8. Specialist :  In every project there are a number of specialist requirements which are dependent upon the nature of the project or the nature of the business. These should be considered separately and explicitly stated within design docs.

THE MYTHICAL MAN MONTH : SIMPLY ADDING RESOURCES IN PROJECT WILL NOT ENSURE EARLIER DELIVERY

Simply Adding Resources to your Project will not Ensure

 Earlier Delivery

In “The Mythical Man Month” Brooks argues Main article: No Silver Bullet 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.

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.

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!

SCOPE TRIANGLE IN PROJECT

SCOPE TRIANGLE IN PROJECT

Scope Triangle’ or the ‘Quality Triangle’ 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 
• 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.

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 fulfill 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.

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.