Projects: Recognising the Need and Justifying the Investment


Posted on 20th May, by JimYoung in Blog. Comments Off on Projects: Recognising the Need and Justifying the Investment

Just because someone has an idea for a project, doesn’t mean it should go ahead.

An organisation’s process for deciding which projects get dropped or deferred (often a euphemism for “dropped”) and which ones get approved is sometimes intuitive, informal, ineffective and inconsistent; the equivalent of rolling dice or the random throwing of darts. Each project has different costs, benefits and risks, and rarely are these known in advance with much certainty.

Rational project selection is an important process, but it’s not easy and many organisations struggle with issues such as running too many projects at once, misaligned business goals and projects, poor co-ordination between projects, lack of management commitment, deficient cross-functional collaboration, resistance to change, reluctance to terminate poorly performing projects, no attempt to check if project benefits have been realised, and finding the right balance between smaller short-term projects that improve current operations and larger long-term projects that increase potential for their organisation’s future survival and competitive advantage.

Also, politics can sometimes play a major role when project sponsors trade favours with decision-makers. Having witnessed local government in action (or inaction), political decision-making about project approval is not always about rational deliberation. Rather, it is often characterised by a struggle for power. This kind of decision-making necessitates bargaining, accommodation, controversy, conflict, bluff, threats, and even deceit. The bottom line is that such project decisions are often the result of bargaining among diverse political interests and not the objective evaluation of viable options in terms of appropriately weighted attributes. More often local government project selection and priorities are decided by emotionally charged city councillors who scream, politic, and subvert in order to push their agenda forward.

The type of working relationships and personal dynamics that develop between the members of a project team, stakeholders and senior management, can determine how smoothly a project progresses and ultimately how successful it is. In a group with good working relationships problems can be dealt with easily and conflicts handled maturely without causing the project to flounder. But where working relationships are fraught with politics and tension, and individuals have their own agendas or are vying to be “top dog” then personal conflicts can get in the way of project success.

Projects might arise from a problem, opportunity or compliance requirement. They might be commissioned to meet a business need, attain a business objective or meet a market demand. They might be top-down in origin, resulting from business planning, or they may arise through unsolicited bottom-up initiatives, external customer requests, mandated needs, or business problems. Most importantly, their identification should be encouraged since maintaining the status quo is not sufficient if organisations are to remain cost-effective, competitive and meet customers’ ever-changing and growing expectations.

Concept Check

Project ideas are always welcome but need to be checked to filter out obvious duds. Only those suggestions that meet threshold selection criteria should be further considered. One key criterion is “strategic fit” – the possible project promises to contribute to the achievement of our organisation’s business objectives. A typical concept checklist is shown here. Such a checklist is designed to identify appropriate project suggestions early on, but a worthwhile suggestion doesn’t necessarily need a positive response against all criteria.

Project Concept Checklist

picc

Project requests that survive this initial concept check then need to be further described and in sufficient detail to enable the development of a project business case, which provides the justification for investing in the proposition. Given this more detailed description of the proposed project, its feasibility and priority can then be established.

Incidentally, we PMs don’t want to manage the lowest priority projects, which are sometimes raided to resource higher priority projects whose costs and resource requirements have been under estimated, and sometimes deliberately so to help ensure their selection. Nevertheless, as new PMs, we may have no option but to accept such failure-prone projects, which are often the result of unrealistic or overly optimistic expectations, and not necessarily the consequence of poor PM. We need to push back against such career-stifling assignments and at least seek realistic resourcing.

“There are more ideas in any organisation, including business, that can possibly be put to use”, Peter Drucker wrote. Given limited resources we need to evaluate possible projects against appropriate and weighted selection criteria or selection attributes, which might include:

  1. Business alignment.
  2. Costs versus benefits.
  3. Risk versus rewards.
  4. Time to financial breakeven.
  5. Opportunity cost.
  6. Consequences of delay in approving the project.
  7. Consequences of not selecting the project.
  8. Technical feasibility.
  9. Availability of resources.
  10. Market demand for the project product.
  11. Legislative compliance.
  12. Environmental impact.
  13. Patent, trademark, copyright and intellectual property considerations.

Aligning our projects to maximise their contribution to business objectives is essential, but if we don’t have such objectives, getting some should be our first project. Every project should contribute to the realisation of our organisation’s purpose and be consistent with our organisation’s core values.

Of these selection criteria, sometimes the “consequences of not selecting the project” can be quite seductive when worrying consequences of the “do nothing” option are predicted. For example, imagine the consequences of not extending the runway at Wellington airport, which would include the loss of an estimated $2.3 billion in economic benefits. When it comes to enabling direct long-haul flights to Asia and America from Wellington, extending the airport runway seems essential. As a user I look forward to saving time, cheaper travel, greater frequency of flights and more options. Other benefits include local growth in tourism, more international students, and migrant attraction. Of course, the anti-extension NIMBY group, “Guardians of the Bays”, reminiscent of the “Save the Basin” lunatics, are working hard to stymie this project, siting the dramatic environmental catastrophes they anticipate will come with any such extension.

People need to stop being short sighted.  Previous examples of this are not having four lanes in the Terrace tunnel, not having a second Mt Vic tunnel and people not being constructive on the Basin flyover. The Airport will need to grow eventually, whether it be demand from long haul or domestic or population growth.  Lengthening the runway is one piece of that growth.  It is better to do it now than do it when it is too late.

People need to stop being short sighted.  Previous examples of this are not having four lanes in the Terrace tunnel, not having a second Mt Vic tunnel and people not being constructive on the Basin flyover. The Airport will need to grow eventually, whether it be demand from long haul or domestic or population growth.  Lengthening the runway is one piece of that growth.  It is better to do it now than do it when t

Frankly, Wellingtonians need to stop being so short-sighted about infrastructure projects.  Previous local examples of this “do nothing” option include not having four lanes in the Terrace tunnel, not having a second Mount Victoria tunnel, and no Basin Reserve flyover. Consider too the Transmission Gully debacle. It took 50 years to get that project underway and in that time the construction costs have blown out from a few million to billions.  In 2013 Prime Minister John Key described Wellington as a dying city, but perhaps this distasteful truth is just a consequence of Auckland’s growth where planned private and public projects have recently cracked the $10 billion mark.

pic1

Business planning, from which many project initiatives are identified, is now a continuous process rather than a discrete half-yearly or annual coven attended by a select few. Part of this planning process is usually a SWOT Analysis, which is a handy mnemonic to help planners think about strategy and identify possible projects.

SWOT Analysis

A SWOT analysis aims to identify the strengths, weaknesses, opportunities and threats of a prospective project. It involves specifying the project goal and identifying the internal and external factors that are favourable and unfavourable to achieving that goal. The strengths and weaknesses arise from within our organisation, and the opportunities and threats from external sources.

Strengths are attributes of our organisation that help us achieve our project goal. We play to our strengths and our questions might be:

  1. Do we have the necessary skills in-house?
  2. Has a budget been assigned to the project?
  3. What are the benefits of completing the project?
  4. Will the project require new technology or equipment?
  5. How experienced is the PM and team?

Weaknesses are attributes of the organisation that work against the achievement of our project goal. We address such weaknesses. Our questions might be:

  1. Is there a reliable estimate of costs available?
  2. Do we have the budget to provide contingency funding?
  3. What are the risks and drawbacks of the project?
  4. Will the project or parts of it need to be outsourced?
  5. Is the project completion date realistic?

Opportunities are external conditions that help us achieve our project goal. We might exploit these opportunities. Our questions might be:

  1. Do the competitors have any weaknesses?
  2. What are the latest product trends and market developments?
  3. Are there any new, or imminent technology developments?
  4. Are there seasonal, weather or fashion influences?
  5. Is there an unfulfilled need?

Threats are external conditions that could jeopardise our project. We hedge against threats. Our questions might be:

  1. Is there a well-established product already in the marketplace?
  2. Are experienced staff difficult to find or replace?
  3. Has new technology been fully tested?
  4. Could economic conditions affect the project?
  5. Could current or pending legislation affect the project?

We may be able to use strengths to overcome weaknesses or to take advantage of opportunities. Once the SWOT factors are identified, we should be better able to identify possible projects and decide if they are worth pursuing.

Costs and Benefits

One very important project selection criterion is costs versus benefits, where:

Value = Benefits less Costs

Return on Investment = (Benefits – Costs) / Costs

Value creation or Return on Investment (ROI) is an organisation’s raison d’être. The above formulae are ridiculously simple and if applied more frequently and more exactingly would go a long way to preventing many project disasters.  If we can’t show value would we do the project? Benefits may be of value to the organisation making the investment, to its staff, to its customers, or even to other parties, but without the generation of benefits for at least one group of stakeholders, there is no justification for investing in the proposed change.

Project Requirements

Project requirements drive the project work scope. Get our requirements wrong and everything we do thereafter is pretty much pointless. Requirements gathering happens way before our project plan is put together. Requirements are the basis for the project product specification and recognise stakeholders’ needs and describe what the users require the finished product to do, whereas a specification is typically a more detailed and explicit technical explanation that shows how the requirements will be achieved.

Defining requirements means identifying the capabilities, features or attributes of the project product.  Stakeholders’ needs, wants and wishes are sought and analysed to derive these requirements that are then prioritised to determine which will be included and excluded. Defining requirements is a continuous process of fleshing out and refining the baseline description of the project product. We should never assume that we know our customer’s requirements, since what we think could be quite different to what our customer wants. To get good requirements, we need to ask the right questions and here are four techniques that may be useful in this regard:

  1. Stakeholder Interviews.  Talk with each key stakeholder and end-user individually to understand each person’s specific views and needs.
  2. Focus Groups.  Conduct group workshops, remembering it’s a good idea to keep asking “why?” for each requirement to help eliminate unwanted or unnecessary requirements. By asking “why” no fewer than five times we usually discover the real requirements.
  3. Case Studies.  A scenario-based technique allows users to walk through the process step by step and helps people understand how the product will work.
  4. Prototyping.  A mock-up or working model of the product gives users a proper 3D-feel of what the final product will do and look like. As a result of this prototype evaluation there may be second and third improved prototypes. Everything from computers to the latest model car, for example, started out first as an idea, then a prototype model, before becoming a finished product.

Sometimes we may find the list of requirements is contradictory or more expansive than our project can address. Requirements must then be analysed and evaluated against the business case to determine which are in and out of scope. Requirements may be expressed as features or functions, although we usually use “function” to describe a product capability and “feature” to refer to physical appearance.

Typically, some 50% of product features and functions are not used or very seldom used. We need to be wary of “Hey, wouldn’t it be cool if we added…” or we might end up with an unnecessarily overloaded, unmanageable, expensive gadget. Yet customers very often select the product with the most features and don’t appreciate the virtues of simplicity – at least until they get the product home and attempt to use it. If it’s an intimidating software product with many features that needs extensive training it was probably the consequence of developers using the Agile PM methodology, which encourages the continuous evolution of requirements rather than devoting sufficient time at the start to define key requirements. Perhaps the impracticable Wenger 16999 Swiss Army knife that contains 85 devices was a consequence of Agile or is at least a terrifying example of requirements’ creep.

Facetious Functionality

pic2

One way of analysing and prioritising product requirements according to their business value and usefulness is to complete a paired-comparisons table or requirements prioritising worksheet. For example, say the office needs a new photocopier, so we canvas the users for their requirements and then working together we prioritise them as shown in this completed example:

Prioritised Requirements

pic3

There may of course be more than 10 requirements in which case the table would need to be expanded. The “Score” is the number of times that the requirement is identified throughout the matrix. As a check, the total score will be 45 if there are 10 items, where:

Total Score = {(Number of Items) x (Number of Items – 1)} / 2

If requirements have the same score we may distinguish between their importance by checking the result when these two requirements are compared. For example, requirements 1 and 9 both scored 3, however, when these two requirements are compared, requirement 1 is of greater priority. Once features and functions are prioritised they may be costed. Budget limitations or cuts might see requirements progressively removed – least important first. All requirements should be unambiguous, clear and measurable.

Requirements may change as our project develops, and as needs and circumstances dictate. These changes can arise from new ideas, new information, new technology, new perspectives, changes in regulations or budget changes, or may be requested by product end-users.  Thus, before we get sign-off on the base requirements list we need to agree the approval procedure for change requests. Unless a proposed change adds value, it would normally be rejected. “Requirements creep” is another expression for feature creep or scope creep.

In summary, requirements specify the capabilities, features or attributes of our project’s product.  Stakeholders’ needs, wants and wishes are sought and analysed to derive these requirements that are then prioritised to determine which will be included in the final product.

Business Case

If our project needs funding, typically a business case is prepared, designed to persuade management to invest the required money, time and resources in the proposed project, rather than in a competing one. The business case evaluates the benefits, costs and risks of alternative options, provides a rationale for the preferred solution, and is based on whole-of-life costs and anticipated benefits to be gained over the same period. The business case underpins our project by describing success in terms of measurable benefits and is arguably the single most important document in our project.

The sponsor is responsible for the business case. In practice the business case may be prepared by a business analyst (BA), but we PMs need to understand it, given it’s the rationale for all we do.  As PMs we appreciate that our management of the project can help or hinder the achievement of business case benefits.  Thus, it’s very helpful if we as the prospective PM are involved in the preparation of our project’s business case.  We will then better understand the reason for our project and help ensure that it’s a realistic pursuit, since those sponsors who are very keen for their projects to proceed have been known to forecast overly optimistic benefits, play down risk, and underestimate costs to create an attractive proposition that transpires to be an impossible challenge for us PMs. Without our input, it’s possible the project charter will mandate something that we cannot accomplish within the time and budget constraints imposed.

The business case for our project comes from one simple line of logic – projects produce products, change management prepares people to use these products, organisations invest in projects to get benefits, and the benefits will not be achieved unless people are using the products and using them properly. Although a group of people may have contributed to the development of the business case, it’s helpful for consistency sake that one person puts it all together. However, sharing drafts with others is a good way to test the arguments and get buy-in.

There’s no magic formula when it comes to the size and structure of a business case, although a common format should help us better compare, select and prioritise competing propositions. A business case does not have to be a written document, but the chances are that if it’s written, we will have edited and proofread it to ensure its effectiveness and have an agreed basis for its periodic review and updating as circumstances change. We should have at least one other person, whose opinion we respect, edit and proofread the document before it’s published.

Sometimes it’s useful to precede the preparation of a business case with a Force Field Analysis whereby project stakeholders brainstorm the driving and restraining forces of the proposed project, but without attempting to quantify the respective arguments, and then work on strengthening the driving forces and/or removing the restraining forces. During 2016 NZ had our flag debate. Some common arguments for and against this option made by binding national referendum are summarised here in Field Force Analysis format.

Proposed Project: Change the National Flag

pic4

 picc5555

How can we ensure that an individual’s passion for a project doesn’t distort the business case? Should we aim to eliminate emotion completely so that the case is made dispassionately? Or should we value emotion as something that stems from a deeply felt sense of what needs to be done to protect and nurture our business? Bringing together several voices, rather than listening to one passionate individual, is essential in order to strike the right balance in such decision-making.

An example business case template is shown here. A written business case might also have a title page, approvals, distribution, a contents page, and an amendment record since it’s a “living document” subject to periodic updating as circumstances change.

Business Case Template

1.   Summary

Depending on the length of the business case we may want to include a summary that mentions the main benefits and costs and our recommendation. Although the summary appears first, it’s written last, when we know what we are summarising.

 2.   Statement of Problem or Opportunity

Describe the business need, problem or opportunity that the project will address.

 3.   Analysis of Options

What are the best alternatives to solve the problem? Here we identify and describe feasible options to solve the problem or capitalise on the opportunity. Basic options may be to outsource the project work or do it ourselves. Buying the product off-the-shelf or leasing may also be options. For example, our options to feed the family are to prepare a meal at home, to get takeaways, or visit a restaurant. The final business case may contain say three or four options that usually include a “do nothing” or benchmark option. And for each option, we need to discuss:

• Benefits. We explain why it would be a good idea to do the project. Benefits may be both qualitative (intangible) and quantitative (tangible / measurable). If benefits are not measured, or are not measurable, then insufficient evidence may exist to justify the investment in the initiative. Informed and accurate decisions around business cases cannot be made unless disbenefits are also identified and measured. Different projects can’t claim the same benefits. For a particular project, benefits to be realised during the next 12 months might be:

  • – Reduce sales administrative costs by 30%.
  • – Increase sales by 5% to 10%.
  • – Lose no existing clients.
  • – Eliminate all errors in the ordering process.

• Disbenefits. We should also identify any significant disbenefits. For example, perhaps the new photocopier will run more quickly but require more maintenance. A very common disbenefit is a reduction in productivity during the time taken for users to learn to properly use a new project product. Of course, disbenefits should not outweigh benefits.

• Costs. We include estimated whole-of-life product costs that include on-going operational, maintenance and support costs.

• Timescale. Estimate of the project duration and time until we see a return on the investment – the financial breakeven point.

• Assumptions and Risks. An assumption is a circumstance or event outside the control of the project that can affect its success, and a risk is a potential problem or opportunity that may impact project success.

Our estimates should be realistic and wherever possible supported by solid data. Also, we need to be balanced in our assessment, meaning for example if indirect, long-term and qualitative estimates are used to determine benefits, the same criteria should also be used for costs to help ensure a fair comparison. However, usually greatest weight is given to short-term, tangible or measurable and direct benefits and costs. Avoid relative terms such as “better”, “lighter”, “cheaper” etc. We might also mention here the consequences of doing nothing. If the return on investment can be quantified as dollars in the form of savings or profits, that will be a great help in building our business case.

 4. Recommended Option

 Here we state our preferred option and explain why it’s recommended.

 5.   Outline Plan

We provide a brief explanation here about how the implementation of the preferred option should proceed.

In a cost benefit analysis, the key component of our business case, it’s dangerous to rely too much on intangible and unquantifiable benefits to justify the investment. In general, a project is approved primarily on its hard-dollar benefits. Unquantifiable or soft-dollar benefits enhance the likelihood of project acceptance, and may encourage commitment from various stakeholders, but these alone are not generally sufficient to justify a project. Short-term outputs that lead to immediate, measurable and substantial benefits are generally the easiest to argue and most persuasive.  Although, for example, while investments in employee health and well-being can be costly in the shorter term, over the longer term such investments may pay off with reduced workplace absenteeism, better retention, greater engagement and productivity, all of which should contribute to the organisation’s bottom line. Also, activities that can initially seem to have a positive effect on finances can be detrimental later on.  For example, encouraging employees to work overtime, rather than hiring more people or outsourcing work, may be cost-effective in the short term, but the longer hours involved may lead to employee demotivation, burn-out, reduced productivity and more absenteeism.  As a result, a project that was originally profitable can end up lemon-like.

One local lemon looks like the proposed Wellington City Council’s $100 million plus cycleways project, the business case for which argues that whole-of-life health and safety benefits will total a very surprising $600 million. I wonder how that figure was determined and I’m picking that Wellington City Council in-fighting, “bikelash” and local government elections will stymie this one. Conversely, the business case for an extended Wellington airport runway seems much more persuasive, but as with the proposed Basin Reserve Flyover project, a handfull of protestors could readily derail the whole proposition.

Financial Evaluations

The reason for any project is to add value, which occurs when benefits exceed costs. Some projects take longer than others to reach this breakeven or payback point. For more expensive longer-term investments, future cash flows may be discounted to present values to help ensure a more accurate financial assessment. The discount rate or hurdle rate, as per the table below, is our organisation’s cost of capital, or for government, Treasury suggest a current default discount rate of 6%, where for example $1,060 return next year is the same as $1,000 today, and is determined by the formula PV = FV / (1+r)n where PV is Present Value, FV is Future Value, r is the interest rate expressed as a decimal (ie, 0.06, not 6%), and n is the number of years.

picc6If NVP is positive after we subtract the cost of the investment, the project is worth proceeding with (from a financial perspective anyway), although other factors might cull the proposition from contention. There are other financial tools that may also be used by an organisation’s financial manager to assess the financial viability of a project.In most cases, discounted cash flow techniques such as net present value (NPV) or internal rate of return (IRR) are appropriate to assess the value of benefits. Here are the various tools used to assess the financial viability of more expensive project propositions:

  1. Payback.  Time taken to recoup the project investment. For example, if double-glazing costs $10,000 and saves $500 a year, the payback period would be 20 years (although personally I hope that climate change will negate the need for any extra warmth).
  2. Cost Benefit Analysis (CBA). It’s a comparison of estimated positive and negative dollar impacts. If net benefits are positive, the project is likely to be worthwhile. Dollarising some factors can be challenging, although I notice that economists have managed to put a value on human life. For NZTA transport funding decisions the current value is $3.56 million per fatality. But in great contrast, the current official price for a human life in the Philippines is a mere 50,000 pesos, which is about NZ$1,500.
  3. Net Present Value (NPV). This requires we add up all the present values of all future cash inflows, and then subtract the sum of the present value of all future cash outflows. If the result is positive the investment is financially favourable.
  4. Internal Rate of Return (IRR). This is the interestrate at which the NPV of all the project cash flows (both positive and negative) equals zero.
  5. Accounting Rate of Return (ARR). This is dollars profit divided by the cost of the investment expressed as a percentage. It ignores the time value of money.
  6. Discounted Cash Flow (DCF). This is an estimate of the money received from a project investment, adjusted for the time value of money.
  7. Economic Value Added (EVA). This is net profit less the equity cost of the organisation’s capital, which is not an easy calculation. The goal is to determine true economic profit after taking into account the opportunity cost of the capital invested in project
  8. Opportunity Cost. Cost of a missed opportunity. For example, the opportunity cost when selecting between two projects is the value of the project that is not selected.

Project and Product Lifecycles

pic7

Evaluating Project Options

A decision matrix can be employed whenever we need to choose among options. Possible options are evaluated against common weighted attributes. We might use this tool when we need to determine which of several projects to proceed with, which proposal to select, which solution to implement, or for any other decision-making occasion.   For example, a company wishing to satisfy an increasing demand for its products might evaluate the following options:

  1. Employees continue to work overtime to meet the sales demand.
  2. Expand the workforce to create the needed capacity.
  3. Contract out some of the work.
  4. Develop more efficient manufacturing processes.
  5. Some appropriate combination of the above options.

It’s important that the selection criteria that are used in a decision matrix are clearly defined. For example, the 2016 NZ Flag Selection Panel determined that a suitable new flag should be: 

  1. Recognisable.  Would be unmistakably and distinctively Kiwi.
  2. Enduring. Would not readily become outdated.
  3. Flexible.  Would work with dignity in all situations.
  4. Simple.  Could be drawn by a child from memory.
  5. Inclusive.  Would represent all New Zealanders.

Suppose the NZ Ministry of Foreign Affairs and Trade (MFAT) needs to decide the best project option for reducing a Pacific Island’s reliance on fossil fuels for electricity generation. The selection criteria or attributes are first identified and prioritised:

Next the prioritised attributes go into a decision matrix. We give each attribute a weight (from say 1 to 10) that represents its relative importance, and then evaluate each option against each attribute, scoring them, where say excellent is 5, satisfactory is 3, and adequate is 1. In this example, the solar power option is preferred. This matrix also allows for easy sensitivity analysis in that the results of a trade-off among the selection attributes is readily observable.

Presenting the Business Case

The final stage of the benefits-focused business case process is to present the business case to our decision-maker(s). The challenge is to keep the story clear, objective and believable. If a decision-maker doesn’t understand it, which they may not publicly admit, they are unlikely to approve it.

Requirements’ Prioritising Table

pic8

Decision Matrix

pic9

If we can, it may be worthwhile to lobby decision-makers before such a decision-making meeting to check if they are on-board, if they have any concerns and if they believe that input from their area has been adequately addressed. Fundamentally, a business case is a tool to sell a new product to our business. If approved, the business case becomes the key input to the project charter.

During the project the business case must be updated to reflect current costs and any other changes. The latest information will be used by the sponsor to assess whether or not the project remains viable. At project closure the updated business case should be handed over to whoever is going to take responsibility for delivering the benefits – usually the project sponsor. It’s the baseline against which to measure project success. Yet, too often the business case is just used to launch the project and once it is launched the business case is shelved.

Project Parameters

Different stakeholders may give different priorities to project parameters. Some project parameters (ie, objectives or conflicting constraints) are usually more important than others. If all parameters are non-negotiable and possess no tolerance the project is over-constrained. The project “driver” is the top parameter – the last to be conceded when the going gets tough. Knowing the driver helps us better manage our project. With regard prioritising PM parameters consider for example the extra 3,000 temporary seating needed at Eden Park to be completed in time for the 2011 Rugby World Cup tournament. The following paired comparisons assessment identified this project as time-driven:

Paired Comparisons’ Matrix

picc10

The driver is what we’ll be judged on – the one area where we must not fail. Thus, in this example, any risk that impacts the completion date for this project must be taken seriously. Also, if time is in jeopardy, we might further degrade product quality or simply spend more money to accelerate progress. Also, a time-driven project would encourage us to put a duration or work effort limit on tasks in order that we might detect schedule slippage as soon as possible. The mantra is “to solve it easily, detect it early.” Fagan’s Law states that the effort expended in resolving an issue, varies exponentially according to the period of time that elapses before the issue is addressed. We should agree parameter priorities with our client and/or sponsor and recognise that project risk and benefits might be affected by parameter priorities.

Some PMs might identify an expanded list of constraints that include the duration or target date for the project, the availability of the project budget, the availability of project resources (such as people, facilities, equipment, materials, infrastructure, tools and other resources) required to carry out the project activities relating to the requirements of the project, factors related to health and safety of personnel, the level of acceptable risk exposure, the potential social or ecological impact of the project, legislative requirements, and anticipated benefits.

Here’s a thought. Quality means that our product meets customers’ needs, is fit for purpose, and provides value for money. While quality is a traditional parameter, perhaps “value” is a more appropriate expression. Value adds a dimension to quality, emphasising that the quality (adherence to specifications) of the solution matters only to the extent the users derive value from the project product. Perhaps keeping value in mind shifts our thinking away from the traditional PM approach to a product approach.  Arguably, cost, scope and schedule are only as important as the impact they have on the value delivered.

We need to ensure that the project justification continues to be valid and that our project will deliver the solution to the business need.  The result of periodic business case reviews may be to confirm, terminate or amend the project. 

In summary, the role of the business case is to show how our project will create additional value for our organisation. The business case provides the justification for committing resources to the project and answers the question “Why do it?” A sound business case underpins a project charter and is a prerequisite for project planning and benefits realisation. When deciding on the criteria for picking projects, it’s natural to focus on ROI (profit or savings), but the focus should also include the full range of benefits the organisation will realise from the project, both tangible and intangible.

 

 

 

 





Comments are closed.



Blog

My latest thoughts on Project Management and life.

BOOK LAUNCH – “Managing Smaller and Medium-Sized Projects”

Authors launching their books sometimes find themselves at a bookstore or other venue surrounded by empty seats except perhaps for their loyal family members,...

Project Durations and Contingencies

Predicting project completion times is one of the challenges of Project Managers. Project schedule overruns are quite common due to uncertainty in estimating task durations,...

Project Cost Estimating

Estimation is notoriously difficult. Projects by definition are unique ventures. We do not have the luxury of “having done it before” enjoyed by our...