Tag: Project Management

Agile Fixed Price Projects

Leave a comment

The Agile fixed price is a contractual model agreed upon by suppliers and customers of IT projects that develop software using Agile methods. The model introduces an initial concept & scoping phase after which budget, due date, and the way of steering the scope within the framework is agreed upon. This differs from traditional fixed-price contracts in that fixed-price contracts usually require a detailed and exact description of the subject matter of the contract in advance.

Fixed price contracts are evil – this is what can often be heard from agilest. On the other hand, those contracts are reality which many agile teams have to face. But what if we try to embrace and manage it instead of fighting against it? How can a company execute this kind of contract using agile practices to achieve better results with lower risk? This article will try to answer those questions.

Fixed Price, Time and Scope

Fixed price contracts freeze three project factors at once – money, time and scope – but this should not be a problem for agile teams. In fact, time boxing is common agile practice. Limiting money simply makes time boxing work better.

A real problem with fixed price contracts is the scope, which is fixed in terms of what should exactly be built instead of how much should we build.

Why are clients so obsessed with fixing the scope? We understand that they want to know how much they will pay (who does not want to know that) and when they will get the product. The only thing they don’t know, even if they will not always admit it, is what exactly they want as the final product.

The reason for fixing the scope has its roots in:

  • Lack of trust between the contractors.
  • Lack of understanding about how the agile software development methodology and processes work.
  • Misunderstanding what the scope means.

Every fixed price contract has a companion document, the “Requirements Specification” or something similar. Most of the time, working in an Agile way, the business requirements are relatively light weight criptic notes captured on stickies or story boards and not in comprehensive Business Requirement Documents (BRDs) pre-approved by business before developemnt commences. Documented requirements tries to reduce the risk of forgetting something important and tries to set a common understanding of what should be done to provide an illusion of predictability of what the business actually wants and needs in the final product.

Key wrong assumptions in fixing the scope are:

  • The more detail we include in the requirements and scope definition up front, the better we understand each other.
  • Well-defined scope will prevent changes.
  • A fixed scope is needed to better estimate price and time.

Converting the Fixed Scope into Fixed Budget

In understanding that the main conflict between application of an agile mindset and a fixed price contract lies in the fixed scope, we can now focus on converting the fixed scope into the fixed budget.

A well defined scope is done by capturing business requirements in as many user stories instead of providing a detailed specification of requirements. These stories are built into a product backlog. The effort required to deliver each story is estimated using one of many story point techniques, like planning poker.

It is key to understand that a higher level of detail in software requirements specifications, means two completely different things for both parties within a contract. Software companies (vendors / supplier), responsible for developing applications, will usually focus on technical details while the company using the software (buying party / customer) is more user focussed and business outcome oriented.

In compiling specifications four key aspects are in play:

  • User stories is a way of expressing requirements, understandable for both suppliers and customers. The understanding builds trust and a sense of common vision. User stories are quick to write and quick to destroy, especially written on an index card. They are also feature oriented, so they can provide a good view on the real scope of a project, and we can compare them with each other in terms of size or effort.
  • Acceptance Ctiteria, captured for each user story, are a formalised list of requirements that ensires a user story is completed with all scenarios taken into account – it specifies the conditions under which a story is fulfilled.
  • Story points as a way of estimating stories, are units of measure for expressing an estimate of the overall effort required to fully implement a user story or other pieces of work on the product backlog. The team will access the effort to deliver a story against the acceptance criteria and in relation to other stories. Various proven estimation techniques can be adopted by the team for example effort can be expressed as a T-shirt size (i.e. Large, Medium, Small). To quantify the effort, each T-shirt size can be assigned a number of story points i.e. Large = 15 storypoints, Medium 5 storypoints and Small = 2 story points. (See also the section on Estimation below). The intention of using story points, instead of man hours, is to lower the risk of underestimating the scope because, story points in their nature are relative and focused on the whole scope or on a group of stories, while traditional estimation (usually done in man-hours) tries to analyse each product feature in isolation.
  • Definition of done is another way of building trust and common understanding about the process and all the future plans for the project. It’s usually the first time clients see user stories and while they may like the way the stories are written, it may not be so obvious what it means to implement a story. Development teams who confirm with the client their definition of done, in conjunction with the acceptance criteria with, illustrate that they know better what the client’s expectations are.Development on a story will be completed when the defenition of done is achieved. This supports better estimation. In addition on the client side, the definition of done, in conjunction with the accpetance criteria, sets the criteria for user story acceptance.

Using the above four aspects, will provide the building blocks to define the scope budget in story points. This story point budget and not the stories behind it, is the first thing that should be fixed in the contract.

This sets the stage for change.

While we have the scope budget fixed (in terms of story points) we still want to embrace change, the agile way. As we are progressing with the project delivery, and especially during backlog refinement, we have the tools (user stories and points) which we can use to compare one requirement with another. This allows us to refine stories and change requirements along the way within a defined story point budget limit. And if we can stay within that limit, we can also stay within the fixed price and time.

Before Estimation

The hardest part in preparing a fixed price contract is to define the price and schedule that will be fixed based on, in most cases, not so well-defined requirements but preferably a well defined scope.

How can you prepare the project team (customer & supplier) to provide the best possible initial estimation?

Educate: Meet with your client and describe the way you’re going to work. We need to tell what the stories are all about, how we are going to estimate them and what is the definition of done. We might even need to do that earlier, when preparing an offer for the client’s Request For Proposal (RFP). Explain the agile delivery mothodology and you will use it to derive the proposal.

Capture user stories: This can be arranged as a time-boxed sessions, usually not taking no more than 1 or 2 days. This is long enough to find most of the stories forming the product vision without falling into feature creep. At this point it is also very important to discuss the definition of done, acceptance criteria for stories, iterations and releases with the client.

We need to know:

  • The environment in which stories should be tested (like the number of browsers or mobile platforms, or operating systems)
  • What kind of documentation is required
  • Where should finished stories be deployed so that the client can take a look at them
  • What should the client do (i.e. take part in a demo session)
  • How often do we meet and who participates
  • etc.

This and probably many more project specific factors will affect the estimation and will set a common understanding about the expectations and quality on both sides. They will also make the estimation less optimistic as it often happens when only the technical aspects of story implementation are considered by the team.

Estimation

Having discussed with the client a set of stories and a definition of done, we can now start the estimation. This is a quite well-known part of the process. The most important activity here is to engage as many future team members as possible so that the estimation is done collectively. Techniques like planning poker are known to lower the risk of underestimation because of some particular team member’s point of view, especially if this team member is also the most experienced-one, which is usually the case when estimations are done be one person. It is also important that the stories are estimated by the people who will actually implement the system.

Apart from T-shirt sizes to expressed effort estiamtion, as mentioned under Story Points above, the Fibonacci-like scale (1, 2, 3, 5, 8, 13, 20, 40, 100) comes in handy for estimating stories in points. Relative estimation starts with finding a set of easiest or smallest stories. They will get 1 or 2 points as a base level for further estimation.

In fact during the initial estimation it is often hard to estimate stories using the lowest values like 1 or 2. The point is, the higher the estimation, the less we know about the story. This is also why estimating in points is easier at this early stage, because it is far easier to tell that a story A is 2x as complicated as story B than to tell that story A will take 25 man-hours to get it Done (remember the definition of done?) and the story B will take 54 hours.

This works well even if we choose 3 or 5 point stories as the base level and if we do that, then it will be easier to break them down into smaller stories later during the development phase. Beware however the stories of 20, 40 or 100 points. This kind of estimation suggests that we know nothing about what is to be implemented, so it should be discussed with the client here and now in a little more detail instead of just happily putting it in the contract.

The result of the estimation is a total number of story points describing the initial scope for a product to be built. This is the number that should be fixed in terms of scope for the contract, not the particular stories themselves.

Deriving the Price and Time

Total number of points estimated based on the initial set of stories does not give us the price and time directly. To translate story points into commercial monetory numbers we need to know more about the development team’s makeup described in the number of differently skilled resources within a team, and the team’s ability to delivery work which is expresessed in an agile KPI referred to as the Team Capacity and/or Velocity.

The team’s velocity refers to the pace, expressed in story points per development cycle or sprint, at which a team can deliver work. The team’s capacity is defined by the average number of story points the team can deliver within a development cycle or sprint. An increase in the velocity, as a result of increased efficiency and higher productivity, will over time increase the teams capacity. Understandably, changing the makeup of the team will impact the team’s velocity/capacity. The team’s capacity and velocity is established through experience on previous projects the team delivered. A mature agile team is characterised by a stable and predictable velocity/capacity.

Let’s use a simple example to demonstrate how the team makeup and velocity are used to determine the project cost and time.

Assume we have:

  • Estimated our stories for a total of 300 story points.
  • The team makeup consists of 5 resources – 3 developers, 1 tester and a team leader.
  • Agile Scrum will be team’s delivery methodology.
  • Experience has shown this teams capacity / velocity is 30 story points over development cycle or sprint length of 2 weeks.

Determine the predicted Timeline

Time = <Points> / <Velocity> * <Sprint length>

Thus…

Time = 300 / 30 * 2 = 20 weeks (or 10 sprints)

Many factors during the project may affect the velocity, however if the team we’re working with is not new, and the project we’re doing is not a great unknown for us, then this number might be actually given based on some evidence and observations of the past.

Now we may be facing one of the two constraints that the client could want to impose on us in the contract:

  • The client wants the software as fast as we can do it (and preferably even faster)
  • The client wants as much as we can do by the date X (which is our business deadline)

If the calculated time is not acceptable then the only factor we can change is the team’s velocity. To do that we need to change the teams makeup and extend the team, however this is not working in a linear way i.e. doubling the team size will nor necessarily double its velocity but it should increase the velocity as the team should be able to do more work within a development cycle.

Determine the predicted Price

Calculating the price is based on the makeup of the team and the assocaited resource/skill set rate card (cost per hour).

The teams cost per sprint is calculated by the % of time or number of hours each reasurce will spend on the project within a sprint.

For our eaxmple, let assume:

  • A Sprint duration of 2 weeks has 10 working days and working 8 hours per day = 80h per sprint.
  • Developer 1 will work 100% on the project at a rate of £100 per hour.
  • Developer 2 will work 50% of his time on the project at a rate of £80 per hour.
  • Developer 3 will also work 100% on the project at a rate of £110 per hour.
  • The Team Leader will work 100% on the project at a rate of £150 per hour.
  • The Tester will be 100% on the project at £80 per hour.

The team cost per sprint (cps) will thus be…

Resource cost per sprint (cps) = <hours of resource per sprint> * <resource rate per hour>

  • Developer 1 cps = 80h * £100 = £8,000
  • Developer 2 cps = 40h (50% of 80h) * £80 = £3,200
  • Developer 3 cps = 80h * £110 = £8,800
  • Team Leader cps = 80h * £150 = £12,000
  • Tester cps = 80h * £80 = £6,400

Total team cost per sprint = (sum of the above) = £38,400 per sprint

Project predicted Price = <Number of sprints (from Predicted Timeline calculation)> * <Team cost per sprint>

Project predicted Price = 10 sprint * £38,400 per sprint = £384,000

So the Fix Price Contract Values are:

  • Price: £576,000
  • Time: 20 weeks (10 x 2 week sprints)
  • Scope: 300 Story Points

These simplistic calculations are of course just a part of the cost that will eventually get into the contract, but they are also the part that usually is the hardest to define. The way in which these cost are calculated also shows how delivering agile projects can be transferred into the contract negotiations environment.

Negotiating on Price

“So why is it so expensive?”, most customers ask.

This is where negotiations actually start.

The only factor a software company is able to change is its man-hour cost rate. It is the rate card that we are negotiating. Not the length of our iteration, not even the number of iterations. Developers, beyond popular believe, has no superhero powers and will not start working twice as fast just because it is negotiated this way. If we say we can be cheaper it is because we will earn less not because we will work faster.

The other factor that can influence the price is controlled by the customer – the scope.

Tracking Progress and Budget

Now that we have our contract signed, it is time to actually build the software within the agreed constraints of time and budget.

Delivering your fixed price project in an agile way is not a magic wand that will make all your problems disappear but it if measured correctly it will give you early visisbility. That is where the project metrics and more specific the burndown graphs come in to play. Early visibility provides you with the luxury of early corrective action ensuuring small problems do not turn into large expesive one’s.

One such a small mistake might be the team velocity used when the project price was calculated. Burndown charts are a very common way of tracking progress in many agile projects. It shows the predicted/forecasted completion of work rate (velocity) against the actual velocity to determine if the project is on track.

Figure 1 – Planned scope burndown vs. real progress.

They are good to visualize planned progress versus the reality. For example the burndown chart from Figure 1 looks quite good:

We are a little above the planned trend but it does not mean that we made a huge mistake when determining our velocity during the contract negotiations. Probably many teams would like their own chart to look like this. But the problem is that this chart shows only two out of three contract factors – scope ( presented as a percentage of story points) and time (sprints). So what about money?

Figure 2 – Scope burndown vs budget burndown.

The chart on Figure 2 shows two burndowns – scope and budget. Those two trends are expressed here as percentages for the purpose. There is no other way to compare those two quantities calculated (one in story points and the other in man-hours or money spent).

To track the scope and budget this way we need to:

  • Track the story points completed (done) in each iteration.
  • Track the real time spent (in man-hours) in each iteration.
  • Recalculate the total points in your project into 100% of our scope and draw a burndown based on percentage of the total scope.
  • Recalculate the budget fixed in the contract (or its part) into a total available man-hours – this is our 100% of a budget – and draw a budget burndown based on percentage of the total budget usedto date.

The second chart does not look promising. We are spending more money to stay on track than we expected. This is probably because of using some extra resources to actually achieve the expected team’s velocity. So having all three factors on one chart makes problems visible and iteration (sprint) 4 in this example is where we start to talk with the client and agree on mitigating actions, before it is too late.

Embracing Change

Agile embraces change, and what we want to do is to streamline change management within the fixed price contract. This has always been the hard part and it still is, but with a little help through changing the focus from the requirements analysis into some boundary limits early in the process, we want to welcome change at any stage of the project.

Remember earlier in the process changed fixed scope into fixed budget. The 300 story points from the example allows us to exchange the contents of the initial user story list without changing the number of story points. This is one of the most important aspects that we want to achieve with a fixed price contract done the agile way.

The difficulty here is to convince the client that stories can be exchanged because they should be comparable in the terms of effort required to complete them. So if at any point client has a new great idea that we can express as some new set of stories (worth for example 20 points) then it is again up to the client if we are going to remove stories worth 20 points from the end of our initial backlog to make a place for the new ones.

Or maybe the client wants to add another iteration (remember the velocity of 20 points per iteration?). It is quite easy to calculate the price of introducing those new stories, as we have already calculated the cost of a sprint.

What still is the most difficult in this kind of contracts is when we find out during the project that some stories will take longer than expected because they were estimated as epics and now we know more about them than we did at the beginning. But still this might not always be the case, because at the same time some stories will actually take less. So again tracking during the contract execution will provide valuable information. Talking about the problems earlier helps negotiating as we can talk about actions that need to be taken to prevent them instead of talking about the rescue plans after the huge and irreversible disaster.

Earning Mutual Trust

All the techniques discussed, require one thing to be actually used succesfully with a fixed price contract and that is – trust. But as we know, trust is not earned by describing but by actually doing. Use the Agile principles to demonstrate the doing, to show the progress and point out the problems early.

With every iteration we want to build value for the client. But what is more important, we focus on delivering the most valuable features first. So, the best way to build the trust of a client might be to divide the contract.

Start small, with some pilot development of 2 or 3 iterations (which will also be fixed price, but shorter). The software delivered must bring an expected value to the client. In fact it must contain some working parts of the key functionalities. The working software proves that you can build the rest. It also gives you the opportunity to verify the first assumptions about the velocity and eventually renegotiate the next part.

The time spent on the pilot development, should also be relatively small when compared to the scope left to be done. This way if our clients are not satisfied with the results, they can go away before it is too late and they no longer need to continue the contract and eventually fail the project.

Summary

Fixed price contracts are often considered very harmful and many agile adopters say that we should simply avoid them. But most of the time and as long as customers request them, they cannot be avoided, so we need to find ways to make them work for the goal, which is building quality software that can demonstrably increase business value propositions and competitive advantage.

I believe that some aspects of a fixed rpice agile contract are even Good and healthy for agile teams, as it touches on the familiar while instilling commercial awareness. Development teams are used to working with delivery targets and business deadlines. That is exactly what the fixed date and price in the contract are – healthy time boxes and boundaries keeping us commercially aware and relevant.

Keep the focus on scope and you can still deliver your agile project within a fixed time and budget.

The intention of this article was not to suggest that agile is some ultimate remedy for solving the problem of fixed price contracts but to show that there are ways to work in this context the agile way.

Advertisement

Solution Design & Architecture (SD&A) – Consider this…

Leave a comment

When it comes to the design and architecture of enterprise level software solutions, what comes to mind?

What is Solution Design & Architecture:

Solution, Design and Architecture (SD&A) is an in-depth IT scoping and review process that bridges the gap between your current IT environments, technologies, and the customer and business needs in order to deliver maximum return-on-investment. A proper design and architecture document also documents the approach, methodology and required steps to delivery the solution.

SD&A are actually two distinct disciplines. Solution Architect’s, with a balanced mixed of technical and business skills, write up the technical design of an environment and work out how to achieve a solution from a technical perspective. Solution Designers put the solution together and price it up based from assistance from the architect.

A solutions architect needs significant people and process skills. They are often in front of management, trying to explain a complex problem in laymen’s terms. They have to find ways to say the same thing using different words for different types of audiences, and they also need to really understand the business’ processes in order to create a cohesive vision of a usable product.

Solution Architect focuses on: 

  • market opportunity
  • technology and requirements
  • business goals
  • budget
  • project timeline
  • resourcing
  • ROI
  • how technology can be used to solve a given business problem 
  • which framework, platform, or tech-stack can be used to create a solution 
  • how the application will look, what the modules will be, and how they interact with each other 
  • how things will scale for the future and how they will be maintained 
  • figuring out the risk in third-party frameworks/platforms 
  • finding a solution to a business problem

Here are some of the main responsibilities of a solutions architect:

Ultimately, the Solution Architect is responsible for the vision that underlies the solution and the execution of that vision into the solution.

  • Creates and leads the process of integrating IT systems for them to meet an organization’s requirements.
  • Conducts a system architecture evaluation and collaborates with project management and IT development teams to improve the architecture.
  • Evaluates project constraints to find alternatives, alleviate risks, and perform process re-engineering if required.
  • Updates stakeholders on the status of product development processes and budgets.
  • Notifies stakeholders about any issues connected to the architecture.
  • Fixes technical issues as they arise.
  • Analyses the business impact that certain technical choices may have on a client’s business processes.
  • Supervises and guides development teams.
  • Continuously researches emerging technologies and proposes changes to the existing architecture.

Solution Architecture Document:

The Solution Architecture provides an architectural description of a software solution and application. It describes the systems and it’s features based on the technical aspects, business goals, and integration points. It is intended to address a solution to the business needs and provides the foundation/map of the solution requirements driving the software build scope.

High level Benefits of Solution Architecture:

  • Builds a comprehensive delivery approach
  • Stakeholder alignment
  • Ensures a longer solution lifespan with the market
  • Ensures business ROI
  • Optimises the delivery scope and associated effectiveness
  • Easier and more organised implementation
  • Provides a good understanding of the overall development environment
  • Problems and associated solutions can be foreseen

Some aspects to consider:

When doing an enterprise level solution architecture, build and deployment, a few key aspects come to mind that should be build into the solution by design and not as an after thought…

  • Solution Architecture should a continuous part of the overall innovation delivery methodology – Solution Architecture is not a once-off exercise but is imbedded in the revolving SDLC. Cyclically evolve and deliver the solution with agility that can quickly adapt to business change with solution architecture forming the foundation (map and sanity check) before the next evolution cycle. Combine the best of several delivery methodologies to ensure optimum results in bringing the best innovation to revenue channels in the shortest possible timeframe. Read more on this subject here.
  • People – Ensure the right people with the appropriate knowledge, skills and abilities within the delivery team. Do not forget that people (users and customers) will use the system – not technologists.
  • Risk – as the solution architecture evolves, it will introduce technology and business risks that must be added to the project risk register and addressed to mitigation in accordance with the business risk appetite.
  • Choose the right software development tech stack that is well established and easily supported while scalable and powerful enough to deliver a feature rich solution that can be integrated into complex operational estates. Most tech-stacks has Solution Frameworks that outline key design options and decision when doing solution architecture. Choosing the right tech-stack is one of the most fundamental ways to future-proof the technology solution. You can read more on choosing the right tech stack here.
  • Modular approach – using a service oriented architecture (SOA) model to ensure the solution can be functionally scaled, up and down to align with feature required, by using independently functioning modules of macro and micro-services. Each service must be clearly defined with input, process, output parameters that aligns with the integration standard established for the platform. This SOA also assist in overall information security enhancements and fault finding in case something goes wrong. It also makes the developed platform more agile to adapt to continuous business environment and market changes with less overall impact and system changes.
  • Customer data at the heart of a solution – Be clear on Master vs Slave customer and data records and ensure the needed integration between master and slave data within inter-connecting systems and platforms, with the needed security applied to ensure privacy and data integrity. Establish a Single Customer and Data Views (single version of the truth) from the design off-set. Ensure personal identifiable data is handled within the solution according to the regulations as outlined in the Data Protection Act and recently introduced GDPR and data anonymisation and retention policy guidelines.
  • Platform Hosting & Infrastructure – What is the intended hosting framework, will it by private or public cloud, running in AWS or Azure – all important decisions that can drastically impact the solution architecture.
  • Scalability – who is the intended audience for the different modules and associated macro services within the solution – how many consecutive users, transactions, customer sessions, reports, dashboards, data imports & processing, data transfers, etc…? As required, ensure the solution architecture accommodate the capability for the system to monitor usage and automatically scale horizontally (more processing/data (hardware) nodes running in parallel without dropping user sessions) and vertically (adding more power to a hardware node).
  • Information and Cyber Security – A tiered architecture ensure physical differentiation between user and customer facing interfaces, system logic and processing algorithms and the storage components of a solution. Various security precautions, guidelines and best practices should be imbedded within the software development by design. This should be articulated within the solution architecture, infrastructure and service software code. Penetration Testing and the associated platform hardening requirements should feed back into the solution architecture enhancement as required.
  • Identity Management – Single Sign On (SSO) user management and application roles to assign access to different modules, features and functionality to user groups and individuals.
  • Integration – data exchange, multi-channel user interface, compute and storage components of the platform, how the different components inter-connects through secure connection with each other, other applications and systems (API and gateway) within the business operations estate and to external systems.
  • Customer Centric & Business Readiness – from a customer and end-user perspective what’s needed to ensure easy adoption (familiarity) and business ramp-up to establish a competent level of efficiency before the solution is deployed and go-live. UX, UI, UAT, Automated Regression Testing, Training Material, FAQs, Communication, etc…
  • Enterprise deployment – Involvement of all IT and business disciplines i.e. Business readiness (covered above), Network, Compute, Cyber Security, DevOps. Make sure non-functional Dev-Ops related requirements are covered in the same manner as
  • Application Support – Involve the support team during product build to ensure they have input and understanding of the solution to provide SLA driven support at to business and IT operations when the solution goes live. 
  • Business Continuity – what is required from an IT infrastructure and platform/solution capability perspective to ensure the system is always available (online) to enable continuous business operations?

Speak to Renier about your solution architecture requirements. With more than 20 years of enterprise technology product development experience, we can support your team toward delivery excellence.

Also Read:

Risk Management – for NEDs

1 Comment

Arguably the most significant adjustment to the NED role over the past seven years is that all NEDs must now be well versed in identifying and managing all forms of risk – operational, financial and reputational…

As a Chairman once described: “Risk is a massive issue now: You need to understand the risks and be clear about what the board is doing about mitigating those risk.”

So, how can you ensure that risks are being articulated appropriately and how can you probe into how risks are being mitigated, irrespective if risk management is well established within an industry or not? In the first part of this article I give some steer on how you can assess current risk management practises (governance) and the latter part covers some best practises.

Risk Maturity

If not already done within the company, you could do a Risk Maturity Assessment which gives an indication of the organisation’s engagement with risk management.

There are various models, usually with five levels of maturity (see the 5 Level Maturity Model in diagram below): from an immature Level 1 organisation where there are no formal risk management policies, processes or associated activities, tools or techniques, through a Level 2 managed organisation where policies are in place but risk reviews are generally reactive, all the ay up to the mature or ‘risk intelligent’ Level 5 enterprise where the risk management tone is set at the top and built into decision making, with risk management activities proactively embedded at all levels of the organisation.

Maturity - 5 Levels

     5 Level Maturity Model 

The outcome of such an assessment will give you clear indication of the risk management maturity level of the organisation. Dependant on how that aligns with the Shareholders’ and Board’s expected level, the needed change actions can be initiated to mature the organisation to the expected level. It will also give you measure of clarity of the rigour of process and review that is likely to have gone into the risk reporting that you see as a Board.

Risk Score/Rating Matrix

As risks are identified, logged in the Risk Register and then assessed based on likelihood of it happening and the impact to the business if it should happen, a Risk Scoring Matrix (with preferably a 5 point scal as per diagram below) is very useful to assign a Risk Score to each risk.

The higher the score the higher the priority of mitigating the risk should be.

RISK Matrix

Risk Score Matrix

As a NED you need to assess the completeness of the Key Risks in the Risk Register. Engaging with the executives prior board meetings goes a long way to get input and a feel for risks existing on the floor (day to day running/operations) of the business. You should also ask if there is something that you are talking about in every meeting that either is not on the risk register, or is rated as a low risk?  If that is true, then you need to explore why you are talking about it as a Board but management are not giving it greater focus.

Risk Heat Chart

A heat chart (as per diagram below) enables a holistic view of risks with high scoring risks in the top right (coloured red) corner and low risks in the bottom left corner (coloured green).Risk-HeatMap

   Risk Heat Map

For a board to get an overview of what the key risks are, I don’t think you can beat a heat chart.

As a NED, you can use this to sense check: Are the risks in the top quadrants, the Red Risks, the ones that the Board feel are the highest risk? Are you talking about these risks regularly and challenging the business on what mitigating actions they are doing to reduce them?

Approach on Risk Review

The popular parlance these days is a ‘deep dive’ into the highest risks, usually undertaken by the Audit Committee.

Apart from the “deep dive’ into risks usually undertaken by the Audit Committee you, as a NED, want to do your own exploring, below is an approached…

1. Current Risk Score

What is the justification for the current rating – does this feel right? The impact should be measured by the potential impact of the risk on strategic objectives, and is usually quite easy to define, but likelihood can be more subjective.

Also known as the mitigated risk rating, the current rating should recognise mitigations or controls that are already in place, and how effective these are.

2. Target Risk Score

What is a reasonable target risk rating for this risk, ie where are we trying to get to?

As a Board, you need to set the risk appetite (which equates to target risk ratings).  This may vary by the type of risk, for example, targeting a very low risk rating might be necessary on something that is a matter of compliance or safety, but in commercial matters, the trade-off between risk and reward needs to be considered, so a higher risk appetite is likely to be acceptable.

There won’t be a limitless budget to spend on mitigating every risk to a minimal level, so as a Board you will have to decide what level of risk you are comfortable with; and where the balance sits between reducing the risk and the cost of mitigation.  Why would you spend more on mitigations than the financial impact of the risk crystallising?

3. Mitigating actions

How are you going to get to your target level of risk?  Planned mitigating actions should drive the risk rating to its target level.  This is a focus area for audit committee deep dives – what actions are planned, and will they be sufficient to bring you to your target risk rating?  Progress on these actions should be monitored regularly – if no progress, ask if this risk being taken seriously enough? Or is it not as big a risk as you first thought?

Good risk management should aid decision making, avoid or minimise losses, but also identify opportunities.

Let’s look now into Risk Mitigation in more detail…

Approach on Risk Mitigation

Risk mitigation can be defined as taking steps to reduce adverse effects and impact to the business while reducing the likelihood of the risk.

There are four types of risk mitigation strategies that hold unique to Business Continuity and Disaster Recovery. When mitigating risk, it’s important to develop a strategy that closely relates to and matches your company’s risk profile.

four types of risk mitigation

Risk Acceptance

Risk acceptance does not reduce any effects however it is still considered a strategy. This strategy is a common option when the cost of other risk management options such as avoidance or limitation may outweigh the cost of the risk itself. A company that doesn’t want to spend a lot of money on avoiding risks that do not have a high possibility of occurring will use the risk acceptance strategy.

Risk Avoidance

Risk avoidance is the opposite of risk acceptance. It is the action that avoids any exposure to the risk whatsoever. It’s important to note that risk avoidance is usually the most expensive of all risk mitigation options.

Risk Limitation/Reduction

Risk limitation is the most common risk management strategy used by businesses. This strategy limits a company’s exposure by taking some action. It is a strategy employing a bit of risk acceptance along with a bit of risk avoidance or an average of both. An example of risk limitation would be a company accepting that a disk drive may fail and avoiding a long period of failure by having backups.

Risk Transference

Risk transference is the involvement of handing risk off to a willing third party. For example, numerous companies outsource certain operations such as customer service, payroll services, etc. This can be beneficial for a company if a transferred risk is not a core competency of that company. It can also be used so a company can focus more on their core competencies.

All of these four risk mitgiation strategies require montioring. Vigilence is needed so that you can recognize and interrperet changes to the impact of that risk.

 

Project Sponsorship

Leave a comment

There are multiple aspects that contribute to a successful project, for example the right people, proper planning, governance, clear roles and responsibilities, but to mention a few. You could argue all equally important but one of the most important aspects that are often overlooked is the position of the Project Sponsor.

In my experience, the Sponsor holds one of the most important roles in terms of project success or failure. An involved sponsor who really is vested in the success of the project, will bring drive and energy to the project at a senior executive level – especially needed when the going gets tough.

The Project Sponsor takes ownership for the project goals, provides overall direction for the project and is the owner of the final product/deliverable.

Project Sponsor – Definition

In PRINCE2 it is not a defined role. PRINCE2 separately defines the “Project Executive” and the “Senior User” – two of the three core elements of the Project Board. For simpler projects these roles may well be combined and this then aligns closely with the general usage of the term Project Sponsor.

The APM Body of Knowledge characterises the Project Sponsor as the individual for whom the project is undertaken and who is the primary risk taker. The Sponsor is a member of the Steering Group which provides strategic direction and will include senior managers and, sometimes, key stakeholders.

The PMI PMBOK Guide talks about project sponsors and project initiators: the project initiator authorises the initiation of a project and the project sponsor provides the financial resources, in cash or in kind for the project. Again, these roles may often be assumed by a single individual.

Who can be a Project Sponsor

It is unusual for Project Sponsors to be full time project professionals. It is more likely that they are drawn from the management team of the business – perhaps as an interested “user”. For major projects it may be the CEO or CIO which assumes the role of Sponsor. It is preferable that the individual brings relevant experience and wields the authority and organisational ability to make things happen.

A sponsor needs to be:

  • a business leader and decision-maker with the credibility to work across corporate and functional boundaries;
  • an enthusiastic advocate of the work and the change it brings about;
  • prepared to commit time and support to the role;
  • sufficiently experienced in P3 to judge if the work is being managed effectively and to challenge P3 managers where appropriate.

Project Sponsor vs Other Project Roles

Project Sponsor vs. Project Owner

The project sponsor is a person.  The project owner is the organization that performs the project and receives its deliverables.  Normally the project sponsor is employed by the project owner organisation.

Project Sponsor vs. Project Manager

The project sponsor is one (and only one) level above the project manager.  While the project manager is responsible for the day to day operations of the project, the project sponsor seeks to promote the project to keep it high on the priority list, ensures the resources are in place to perform the project, and approves changes to the project.

Project Sponsor Project Manager
Day to Day management of project work No Yes
Project Deliverables Accepts Produces
Funding Approves Requests

The two main differences between project sponsorship and project management 

    1. Project sponsorship includes the identification and definition of the project whereas project management is concerned with delivering a project that is already defined, if only quite loosely.
    2. The project sponsor is responsible for the project’s business case and should not hesitate to recommend cancellation of the project if the business case no longer justifies the project.

Quick look at Other Project Roles:

    • Project Manager:  Responsible for the day to day project work, keeping the project on schedule and budget.  They report to the Project Sponsor.
    • Project Team:  The people who perform the technical project work and produce the deliverables.  They report to the project manager.
    • Customers/Users:  The people who use the project deliverables to improve their lives or work.  They are sometimes involved directly within the project in the form of focus groups or test subjects.
    • Vendors:  The people and organizations the project procures to provide products and/or services to fill technical gaps in the project team’s knowledge or ability, or to enhance the quality of the final product.
    • Business Partners:  The people or organizations that the project owner partners with to fulfill a specific role like installation, training or support.
    • Functional Managers:  The managers of technical groups (departments) within the owner organization, who often supply technical expertise to the project.
    • External Stakeholders:  Most project have stakeholders who are affected by the project, like government regulatory agencies, adjacent landowners, and the like.

Sponsor Responsibilities

The role of project sponsor is critical to ensuring the success of projects – therefore, when initiating a new project, you need to define the project sponsor taking into account the importance of project sponsorship. A project sponsor is to be involved from project initiation to project end. They represent the business side of the project.  They were probably involved when the project was being conceived and advocated for its inception before a project manager was assigned.

Further the sponsor is critical to strategic planning, high project sustainability, and successful implementation of project objectives. The role of project sponsor covers the financial and organizational responsibilities and activities that are directed to quick and decisive governance of the project.

The project sponsor is one, and only one, level above the project manager.  They do not manage the day to day operations of the project but they ensure the resources are in place, promote the project, and hold overall responsibility for the project’s success.

A good sponsor performs different functions during the project life cycle, serving as mentor, catalyst, motivator, barrier buster, and boundary manager. Most of the sponsor responsibilities are covered below:

  • The sponsor is the link between the project manager and senior managers, lead negotiations to gain and ensure stakeholder consensus.
  • Champion/Promotion: The project sponsor is the best ‘project seller’ that champions the project thought the business. The sponsor promotes and defends the project in front of all other stakeholders. They are the project champion that attempts to keep the project at the highest priority within the organisation.
  • Informing:  They receive project status updates from the project manager and disseminate the information to the relevant executives.
  • Project Charter:  This document officially creates the project and assigns the project manager.  It falls directly within the project sponsor’s responsibility.
  • Authorisation: They authorise the project and assign the project manager. They approve the project management plan and are kept aware of how the project is managed.
  • Scoping:  They are generally responsible for determining the initial project scope, although the project manager is ultimately responsible for the official project scope within the project management plan.
  • Goals: The Sponsor should ensure that the business need is valid and correctly prioritised within the project.
  • Communication: Clearly communicate on aspects of the project with stakeholder groups and senior management.
  • Keeping to Schedule: The Sponsor is heavily involved in ensuring that the project is kept to the original schedule along with the Project Manager. In order to manage the schedule the Sponsor and Project Manager should meet frequently and review the timeline.
  • Changes: A project can experience changes at any time. The Sponsor needs to ensure that these changes are properly managed to ensure that they don’t have any negative impact on the project.
  • Resolve Risks & Issues: Some issues are out of the reach of the Project Manager such as decisions on changes and conflicting objectives. The Sponsor takes control of these issues and ensures that they are solved efficiently and effectively.
  • Support: The Project Manager needs consistent support during a project. The Sponsor is on hand to provide this support in the form of mentoring, coaching and leadership. The Sponsor also supports the Project Team especially in terms of scope clarification, progress management and guidance.
  • Reporting: Assistance for the PM with appraisal and reporting.
  • Funding: They are responsible for negotiations to ensure funding is in place and approving changes to the project budget.
  • Leadership: Provide direction and guidance for project empowerment, key business strategies and project initiatives.
  • ROI & Benefits: As owner of the business case, the project sponsor is responsible for qualifying and overseeing the delivery of the benefits (the benefits realisation) as well as to identify project critical success factors and approve deliverables.
  • Identify members of Steering Committee and chair these Steerco meetings.
  • Involve stakeholders in the project and maintain their ongoing commitment to the project through using communication strategies and project management planning methods
  • Receiving:  Evaluate the project’s success on completion – The project sponsor receives the project deliverables from the project manager, approves them, and integrates them into the owner organization.

According to the Project Management Institute (PMI), the project sponsor role can be broken into three parts: vision, governance and value or benefits realization. They break those down in the following way:

Vision

    • Makes sure the business case is valid and in step with the business propositio
    • Aligns project with business strategy, goals and objective
    • Stays informed of project events to keep project viable
    • Defines the criteria for project success and how it fits with the overall business

Governance

    • Ensures project is properly launched and initiated
    • Maintains organizational priorities throughout project
    • Offers support for project organization
    • Defines project roles and reporting structure
    • Acts as an escalation point for issues when something is beyond the project manager’s control
    • Gets financial resources
    • Decision-maker for progress and phases of project

Values & Benefits

    • Makes sure that risks and changes are managed
    • Helps to ensure control and review processes
    • Oversees delivery of project value
    • Evaluates status and progress
    • Approves deliverables
    • Helps with decision-making
    • Responsible for project quality throughout project phases

Common reasons why the Sponsor lets down the project:

Many organisations invest heavily in project management training but are blind to the benefits of having project leaders who truly understand how projects differ from other management activities. Business are letting a project down if the sponsor:

    • is reassignment in the organisation, or distraction by other priorities.
    • is micro managing which can disrupt project manager confidence and authority.
    • fails to understand the project process and responsibilities.

The chances are that if an inappropriate project sponsor has been chosen,

    • the effectiveness of the role is reduced,
    • the project is not funded sufficiently,
    • and the overall success of the project is likely to turn into failure.

In fact, any project which is initiated without an appropriate degree of executive sponsorship (executive sponsor) stands an high likelihood of failure.

Sponsorship: project, programme or portfolio

Project

The role of the project sponsor starts before the appointment of the project manager. It continues beyond project closure and the departure of the project manager. So the sponsorship role covers the whole project life cycle.

The project sponsorship role will often be taken by the programme manager where the project is part of a programme.

Programme

The scale of programmes will often require a sponsor to be supported by a group of senior managers who perform some sponsorship duties. However, ultimate accountability will lie with the programme sponsor.

The programme manager should also be a competent project sponsor and will often perform that role for some, or all, of the programme’s component projects.

Portfolio

Sponsorship of a portfolio of projects and programmes will be undertaken by a senior executive with the necessary status, credibility and authority. This may well be a main board member, or even the CEO of the organisation. The scale of a portfolio will require an extensive governance organisation. This may involve, for example, committees with the responsibility for investment decisions or management of change.

What a Project Sponsor Does In Each Phase

While sometimes a project sponsor is clearly engaged from the start and other times they are nowhere to be seen, the best project sponsor is fully engaged with every phase of the project.

Initiation Duties

Project sponsors are instrumental in selecting the project manager during the initiation phase, and then they give that project manager a clear mandate, context for the project and set the level of their authority.

Also, during the project initiation, the project sponsor makes sure the project is appropriate for the organization, offering input on the project charter and participates in the kick-off meeting. The sponsor helps with the decision making during this phase.

Planning Duties

For the planning phase, the project sponsor is checking to make sure the project plan is realistic and feasible. This accounts for time restrictions and whether or not the team is tasked with expectations they cannot meet.

The project sponsor can help resolve issues, too, if they’re beyond the scope of the project manager. If there are other projects in play, the project sponsor is making sure they’re all working together and not against each other.

Implementation Duties

For the implementation and control phases, the project sponsor should work with the project manager, but not overstep boundaries. The project sponsor evaluates the project’s actual progress against what was planned and provides feedback to the project manager as necessary.

Sponsors also help the project manager and team work more autonomously to solve issues as they arise, while making sure that processes are being followed. They identify underlying factors that might cause problems and celebrate completion of milestones.

Closing Duties

During the closing phase, the project sponsor is part of the post-mortem evaluation on performance and other aspects of the project. They make sure that handoffs and signoffs are done properly. Project sponsors help facilitate the discussion that decides whether a project was a success or failure.

Overall, a project sponsor helps to streamline communications. They create trust and collaboration and keep problems from escalating. In terms of issues, they set up the instrument to identify problems with schedule, cost and quality. In that sense, they’re also in charge of making sure risk management is successful. Finally, they also encourage record-keeping for historical data storage.

Project Retrospective

Leave a comment

These meetings go by many names – lessons learned, postmortems, retrospectives, after-action reviews, wrap-ups, project “success” meetings. Regardless of what you call them, they all have the same goal and follow the same basic pattern.

Retrospective – looking back on or dealing with past events or situations oran exhibition or compilation showing the development of work over a period of time.

An Agile retrospective is a meeting that’s held at the end of an iteration (sprint) in an agile project. During the retrospective, the team reflects on what happened in the iteration (sprint) and identifies actions for improvement going forward.

The Project Retrospective dedicates time to reviewing a completed project and learning from both the successes and the failures so the team and organisation can improve how they work going forward.

The general purpose is to allow the team, as a group, to evaluate its past working cycle. In addition, it’s an important moment to gather feedback on what went well and what did not.

Classic questions answered in these meetings:

  • What did we set out to do?
  • What actually happened?
  • Why did it happen?
  • What are we going to do next time?

 

“We do not learn from experience … we learn from reflecting on experience.”; John Dewey

Retrospectives give a team time to reflect on what they learned.

 

The Process

The process for debriefing a project covers roughly the same topics as the quick after-action discussion.

  1. Review the Project
  2. What went well and did not
  3. How can we do it better next-time

Review the project

Start by reviewing the project facts: goals, timeline, budget, major events, and success metrics.

In order to come up with useful ideas that everyone can agree on, the team needs a shared understanding of the facts and insight into the parts of the project in which they may not have been involved.

It’s important not to skip or rush through this step, especially for larger projects. People will arrive at the retrospective ready to discuss and solve problems, often assuming they know everything they need to know about what happened. This is rarely true.

If you are reviewing a project as a team, that means it took many people with unique experiences to get to that point. This step ensures everyone gets all the facts straight before they try to solve problems they may only partially understand.

What went well and what did not

This is the heart of the meeting. Everyone shares what they learned during the project: both the good and the bad.

In my opinion, this is the most fun and most challenging part of the meeting. As the meeting leader, you have an enormous impact on the success of your retrospective by deciding which questions you’ll ask and how the team shares their answers.

How can we do it better next-time

Real change is the ultimate measure of a retrospective’s success. To ensure that your retrospective results in something actually getting better, you’ll end the meeting by creating a specific action plan for improvements.

Ambit Enterprise Upgrade

Leave a comment
Sep ’19 – The latest version of Ambit Enterprise software have been deployed for Shawbrook Bank’s Business Finance division.
As Programme Director, Renier was responsible for managing the integration and delivery, software development and implementation of the Enterprise version of Ambit for 15 specialist asset-finance business units and their associated product offerings.
Ambit Asset Finance Software meets its customer’s diverse set of requirements by not only bringing to market scalable, flexible, and industry-leading software solutions, but delivering and supporting these applications in fully managed and hosted environments.
Read more about the FIS Asset Manage Solution – Ambit, FIS Ambit Asset Finance Solution.
#Lead #Direct #ProjectManagement #AssetFinance

GANTT Charts

1 Comment

A Gantt chart is a horizontal bar chart developed as a production control tool in 1917 by Henry L. Gantt, an American engineer and social scientist. Frequently used in project management, a Gantt chart provides a graphical illustration of a schedule that helps to plan, coordinate, and track specific tasks in a project.

Gantt charts may be simple versions created on graph paper or more complex automated versions created using project management applications such as Microsoft Project or Excel.

A Gantt chart is constructed with a horizontal axis representing the total time span of the project, broken down into increments (for example, days, weeks, or months) and a vertical axis representing the tasks that make up the project (for example, if the project is outfitting your computer with new software, the major tasks involved might be: conduct research, choose software, install software). Horizontal bars of varying lengths represent the sequences, timing, and time span for each task. Using the same example, you would put “conduct research” at the top of the verticle axis and draw a bar on the graph that represents the amount of time you expect to spend on the research, and then enter the other tasks below the first one and representative bars at the points in time when you expect to undertake them. The bar spans may overlap, as, for example, you may conduct research and choose software during the same time span. As the project progresses, secondary bars, arrowheads, or darkened bars may be added to indicate completed tasks, or the portions of tasks that have been completed. A vertical line is used to represent the report date.

Gantt charts give a clear illustration of project status, but one problem with them is that they don’t indicate task dependencies – you cannot tell how one task falling behind schedule affects other tasks. The PERT Chart, another popular project management charting method, is designed to do this. Automated Gantt charts store more information about tasks, such as the individuals assigned to specific tasks, and notes about the procedures. They also offer the benefit of being easy to change, which is helpful. Charts may be adjusted frequently to reflect the actual status of project tasks as, almost inevitably, they diverge from the original plan.

Also Read…

Management Communication Plan

PERT Charts

2 Comments

A PERT chart is a project management tool used to schedule, organize, and coordinate tasks within a project. PERT stands for Program Evaluation Review Technique, a methodology developed by the U.S. Navy in the 1950s to manage the Polaris submarine missile program. A similar methodology, the Critical Path Method (CPM) was developed for project management in the private sector at about the same time.

PERT Chart 1

A PERT chart presents a graphic illustration of a project as a network diagram consisting of numbered nodes (either circles or rectangles) representing events, or milestones in the project linked by labelled vectors (directional lines) representing tasks in the project. The direction of the arrows on the lines indicates the sequence of tasks. In the diagram, for example, the tasks between nodes 1, 2, 4, 8, 9 and 10 must be completed in sequence. These are called dependent or serial tasks. The tasks between nodes 2 and 3, and nodes 2 and 4 are not dependent on the completion of one to start the other and can be undertaken simultaneously. These tasks are called  parallel or concurrent tasks. Tasks that must be completed in sequence but that don’t require resources or completion time are considered to have event dependency. These are represented by dotted lines with arrows and are called dummy activities. For example, the dashed arrow linking nodes 6 and 9 indicates that the system files must be converted before the user test can take place, but that the resources and time required to prepare for the user test (writing the user manual and user training) are on another path. Numbers on the opposite sides of the vectors indicate the time allotted for the task.

The PERT chart is sometimes preferred over the Gantt Chart, another popular project management charting method, because it clearly illustrates task dependencies. On the other hand, the PERT chart can be much more difficult to interpret, especially on complex projects. Frequently, project managers use both techniques.

Also Read…

Management Communication Plan

Project Failure? How to Recover and/or Prevent…

Leave a comment

Statistics indicate that 68% of all IT projects are bound to failure!

The PMI’s definition of a high-performing organisation, is a company that completes 80% or more projects on time, on budget, and meeting original goals. In a low-performing organization, only 60% or fewer projects hit the same marks.

Projects fail for all kinds of reasons:

  • Stakeholders can change their objectives
  • Key team members can leave for other companies
  • Budgets can disappear
  • Materials/Vendors can be delayed
  • Priorities can go un-managed
  • Running out of time
  • …and others

In this post:

> How to prevent project failure (with some statistics)

> How to recover a failing project

How to prevent project failure

Prevention is the best cure, so what can you do to prevent projects from failing? Here is some statistics…

  • Organisations that invest in proven project management practices waste 28 times less money because more of their strategic initiatives are completed successfully.
    Source: PMI’s Pulse of the Profession Survey, 2017.
  • 77% of high-performing organizations have actively-engaged project sponsors, while only 44% of low-performing organizations do.
    Source: PMI’s Pulse of the Profession Survey, 2017.
  • 46% of CIOs say that one of the main reasons IT projects fail is weak ownership.
    Source: The Harvey Nash/KPMG CIO Survey, 2017.
  • 33% of IT projects fail because senior management doesn’t get involved and requirements/scope change mid-way through the project.
    Source: A Replicated Survey of IT Software Project Failures by Khaled El Emam and A. Güneş Koru, 2008.
  • 78% of respondents feel that business is out of sync with project requirements and business stakeholders need to be more involved in the requirements process.
    Source: Doomed from the Start Industry Survey by Geneca, 2011.
  • 45% of the managers surveyed say business objectives are unclear to them.
    Source: Doomed from the Start Industry Survey by Geneca, 2011.
  • Companies that align their enterprise-wide PMO (project management office) to strategyhad 38% more projects meet original goals than those that did not. They also had 33% fewer projects deemed failures.
    Source: PMI’s Pulse of the Profession Survey, 2017.
  • 40% of CIOs say that some of the main reasons IT projects fail is an overly optimistic approach and unclear objectives.
    Souce: The Harvey Nash/KPMG CIO Survey, 2017.
  • Poor estimation during the planning phase continues to be the largest (32%) contributor to IT project failures.
    Source: PwC 15th Annual Global CEO Survey, 2012.
  • Projects with effective communication are almost twice as likely to successfully deliver project scope and meet quality standards than projects without effective communication (68% vs 32% and 66% vs 33%, respectively.)
    Source: PwC 15th Annual Global CEO Survey, 2012.

How to recover a failing project

These statistics show that the odds are not in your favour. It is inevitable that you will have to deal with a failing project or two, some time within your career… You could turn the odds in your favour by taking action in recovering failing projects.

Here are four steps you can use that could save a failing project — backed up by original research from Gartner, iSixSigma, PMI Project Zone Congress, The Institution of Engineering and Technology, and Government CIO Magazine. Follow these four steps and salvage your failing project!

Step 1: Stop and Evaluate

Step 1 – Big action items:

  • Issue a “stop work” order
  • Talk with everyone

Metrics/Indicators: The right project Management Information (MI) should give you the needed early warning signs when things are not going according to plan and heading to failure. These signs should drive you to action, as rescuing a failing a project is not a task to be sneezed at. It takes planning, and the process can consume weeks of key resources time and effort.

People: To help ease the pain of stopping a project, work with the team members’ managers (resource owners) to identify and assign interim work. As people are your most important asset, it is important to keep them productively engaged while you are evaluating and re-planning your project recovery.

Project artefacts/deliverables: Make sure all the project artefacts and deliverables are safely stored where it cannot be tampered with for the interim period.

Communicate: (clear, concise, and concrete) – Communicate to your team why their project is on hold. Spend the needed time to learn as much as you can about each team member’s opinions of the project and of each other. Learning that their project will be put on hold will inevitably create distrust. Transparency and tailored messaging is the best way to mitigate bad feelings. See blog posts “Management Communication Plan” and  “Effective Leadership Communication”

Project/Delivery Manager (You):Check your ego. Go to the major stakeholders and ask for anonymous feedback on their view of the overall project. When evaluating their responses, don’t forget to consider company culture and politics and how those factors may have played a role in forming the stakeholders’ opinions.

Step 2: Why your project is failing – Root causes

Step 2 – Big action items:

  • Establish allowable solutions for project rescue (including project termination)
  • Identify root causes of the problem
  • Identify risks to project continuation

Determine the root causes: Most times the cause of project problems is not immediately obvious. Even the best project managers — those with excellent project plans, appropriate budgets, and fantastic scope control — also struggle, on occasion, with project failure.

You’ll only get to the bottom of it by doing a Route Cause Analysis (RCA) and the “5 Why’s” technique can help with that. See “The 5 Whys for route cause analysis”

Surface-level answers are often the temptation when project managers reach this step. They might focus on the complexity of their project, their outdated project management softwareor methodology, their unclear objectives or their stakeholders’ lack of involvement. All of these problems are so generic that they don’t provide enough insight to create real solutions.

Apply the “5 Whys” and be specific when answering these questions… i.e.

  • Why are objectives unclear?
  • Why aren’t users getting involved?
  • Why are the estimates wrong?

Of course, some of these answers may be hard to hear, and solutions can range from the challenging to impossible. Remember: if these issues could be easily remedied, they would have been addressed and resolved. Even simple problems — like a team member leaving — can take months to fix. Ask yourself: are you using the right technology for the job? Are your dependencies so external that project control is simply out of your hands?

If you’re still struggling to figure out where the root of your project failure is, consider these seven issues – the most common causes of project failure.

  • Complexity
  • External
  • Financial
  • Operational
  • Organizational
  • Schedule
  • Technology

Risk Assessment:What are the risks when trying to salvage the project? Are those risks worth it? Is the project salvageable? Answer these questions before moving on.

Step 3: War Room

Step 3 – Big action items:

  • Set up the war room
  • Re-engage stakeholders
  • Create a tentative plan to move forward

Okay, General!

Assemble the team, seat them all together, and work through a rescue workshop. You’re in the mentality of “kill” or “fix” you’re done fact finding, asking question for further research, or finding other excuses to delay the process. That should all have been done in step two. You’re focussed to figure out what to do with your project.

The “war room” will be intense – all members need to be prepared and the right mindset  of problem solving!

The decision-making process could take two hours or several days. All key decision makers must be present. As this is not always possible some executives may prefer to be called in as the meeting is nearing its end, where team members can present prepared options.

To get the most out of the workshop, conduct the meeting face to face (take the meeting offline). Try to limit the meeting to ten people, including the most important stakeholders (like the sponsors), project manager, senior team members including technical representative to give insight to plan feasibility.

The war room is serious business –  prepare for it. Create an agenda to go over findings, from quantitative reporting to team member interviews. Encourage pre-war-room collaboration (covering the outcomes of steps 1 and 2) toward the ideal shared result.

When you start the war room meeting, all project material should be readily available. That’s your fact base driving factual data driven assumptions and decisions.

Using the facts, the purpose of the war room, in essence, is to answer three deceptively complex questions:

  • Is the business case still valid?
  • If the business case is no longer valid, is there potential for a new, reimagined, justified business case?
  • (If so): Are the added costs for project rescue worth it?

Encourage your task force to focus on identifying the project’s primary drivers (i.e. business need/value, budget, schedule, scope, or quality). Ideally, there should only be one driver that controls the outcome of the project – this is usually the business need for the project’s deliverables.

Sometimes the primary driver is beyond repair. For example, if the core due date has passed and it was aligned with a market cycle (ex: Black Friday to Christmas), then the project is irremediable.

Least case scenario: Clearly articulate the primary goal. Then identify what the team can do with the least amount of effort. Develop a scenario that costs the company the least and gets closest to achieve the primary goal.

Project termination considerations: If the primary goal cannot be achieved, prepare a recommendation to terminate the project… but not without scrutiny. Several variables must be considered and thoroughly addressed in the war room.

  • Consider trade-offs that could make the worst-case scenario more possible than originally thought.
  • Think about the potential backlash from killing a project.
    • How does that decision affect business strategy?
    • Other projects?
    • Public perceptions?
    • Potential future clients? All these variables must be considered and thoroughly addressed in the war room.

Alternatives: Should the least-case scenario makes sense, explore more alternatives. Are there alternative options that can deliver more of the project’s objectives, and consider how adding those solutions to your plan can create additional potential scenarios — positive or negative.

New project charter: Write down the main points of your plan in a revised project charter.

Replacement project option: It’s not uncommon for stakeholders to propose a replacement project instead of a rescue. That’s a totally viable option — kill the project, salvaging only essential, functional portions of the original attempt, and work to create a new plan.If the decision is to completely start over, abandon project rescue altogether. Justify the replacement project on its own merit (a new scope, budget, resource plan, etc.)

Step 4: Set your project in motion

Step 4 – Big action items:

  • Finalise how your project will move forward
  • Confirm responsibilities
  • Reset organizational expectations.

Following your war room meeting, your next steps are all about follow-up. The real project rescue starts here and is the most challenging part of project rescue.

Re-engage stakeholders around the contents of the new project plan and complete the detail with precise commitments for each team member. Plans should be finalised within two days.

Be careful as hesitation and procrastination can limit team commitment and lower morale. You’re the general; get your troops ready to re-engage and to stay committed and focussed!

Reconfirm all project metrics: Validate all project aspects especially resources, as people has been allocation to productive work while you were reworking your rescue plan.

As the project rolls forward, be sure to detail the new project’s profile, scope, and size to the core team and beyond. Emphasize expected outcomes and explain how this project aligns with the company’s goals. Don’t shy away from communicating what these changes can mean on a big-picture scale. While you may receive some feedback, be direct: the project is proceeding.

Make sure all communication is clear. Confirm that stakeholders accept their new responsibilities to the project.

The Art of IT Effort Estimation

Leave a comment

Why Estimate at all?

Estimation is an essential part of any project methodology. Estimation is used for a number of purposes:

  • To justify the project enabling the costs to be compared with the anticipated benefits and to enable informed comparisons to be made between different technical or functional options.
  • To enforce the discipline needed to make the project succeed.
  • To secure the resources required to successfully deliver the project.
  • To ensure that the support impact of the project is fully understood.
  • To inform and improve the software development process.

What is estimation and why is it so important

Projects are planned and managed within scope, time, and cost constraints. These constraints are referred to as the Project Management Triangle.  Each side represents a constraint.  One side of the triangle cannot be changed without impacting the others. The time constraint refers to the amount of time available to complete a project. The cost constraint refers to the budgeted amount available for the project. The scope constraint refers to what must be done to produce the project’s end result.

These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope.

PM 3 Constraints

What are the challenges

  • Lack of communication between…a…b…c
  • Lack of training in basic knowledge and techniques of estimation
  • Inability to do estimations based on – cost – time – scope
  • Project failure through time over runs and faulty estimation

Where are we going wrong?

  • Every day, project managers and business leaders make decisions based on estimates of the dynamics of the project management triangle.
  • Since each decision can determine whether a project succeeds or fails, accurate estimates are critical.
  • Projects launched without a rigorous initial estimate are five times more probable of experiencing delays and cancellations.
  • Even projects with sound initial estimates are doomed if they are not guided by informed decisions within the constraints of the triangle.
  • If you are working under a fixed budget (cost constraint), then an inaccurate estimate of the number of product features you can produce (scope) within a fixed period of time (schedule) will doom your project.
  • Inaccurate estimates across your projects de-optimize your portfolio.
  • Estimates are always questioned when estimates are given with knowledge – no estimation template is being used

How can we improve?

  1.  Outsource the project estimation function to an outside qualified consultant for each project to be able to gain viable and realistic project estimations that can be achieved.
  2.  Education of in-house project managers and technical leads so that we are able to collectively able to provide clear methodologies on how to estimate accurately.

This can be done through an onsite workshop/course  – onsite is cost effective as company will pay one block fee for the attendees instead of delegates going offsite and attending a workshop where individual fees are applicable.

My personal recommendation is option B – as this option will allow us to retain skills in house to be able to produce accurate estimates

What are the long term benefits

Well crafted estimate creates many benefits:

  • alignment between business objectives and technical estimates
  • more informed business decision making
  • reliable project delivery dates
  • improved communication between management and the project team
  • controlled project costs, and
  • satisfied customers

Conclusion

The UK is facing ever tightening economic restraints. This means the quality of work is now, more than ever, of the utmost importance. To stay competitive in a shrinking marketplace, this company cannot afford to get a reputation in the industry for non-performance and bringing in projects over budget and outside estimated time frames. Credibility is the basis on which we build our reputation. In the eyes of clients credibility = successful projects. For us the success of all projects rest on the correct and precise estimation from the start of a project based on best practices, realistic expectations and transparency.