Skip to main content

Tag: Plan

Rescuing a Troubled or Failing Project

Written by Barry Currry on . Posted in Articles. 12 Comments on Rescuing a Troubled or Failing Project

Project Managers from time to time are called in to help rescue projects that are failing. Here are a few areas a Project Manager…

could focus on when determining the corrective action needed to bring a project back on track.

Background to the Problem

The first action is to understand why you have been called in to support or help rescue the project– what is the nature of the problem or problems? – Have the issues been defined? What was the trigger that caused the client to take action? How did the client recognize that there was a problem?

What is the project problem statement?

Understanding the background and current situation of the project allows the project manager to formulate a more effective corrective action plan to bring the project back on track. Some questions to ask are:

  • Has the issue been clearly understood?
  • What has lead the client to recognize that there are problems with the project?
  • How is it known that there are problems?
  • What evidence is available? Assume nothing here.

When did the issue first occur?

Understanding the timeline of when issues and problems occurred within the project can also assist in putting together a root cause of the issues and problems the project is facing.

When was the problem first recognized?

When did the project stake holders officially recognize that the project is failing and needed help? When posing this question, it is important to understand the difference between the symptom and the underlying cause. A symptom is the effect of the problem, and although related to the problem, the focus should remain on the reasons behind or the cause of the symptom.

The first symptom may have manifested itself sometime after the root cause event that triggered the symptom. Therefore – How did the problem first manifest itself? What evidence is available to substantiate the claims?

Looking at the key performance indicators of most projects – these include:

  • Schedule
  • Cost
  • Scope

Is the project late on a number of key milestones?

Is the project greatly over budget?

Has the scope of the project changed?

What controls are in place to monitor these KPIs? When were they first flagged and by whom and why?

Understand Key Process Indicators or Project Health Indicators that are used on the project. It is helpful to understand how these indicators are calculated, how frequently they are reported, and the history of indicator results over a period of time.

Previous Action Taken

Previous attempts at taking corrective action should also be fully understood. Ideally, you don’t want to try to take a corrective action that had previously failed. You can also learn as to why corrective actions failed so that that corrective actions that you put in place don’t fail. Some questions to consider:

  • What action has been taken so far?
  • What has been done by whom and when in the initial stage of the investigation into the failing project? This needs to be understood because early action without research or careful thought I have made the issue worse.
  • Has someone recorded what he or she have done and recorded the impact of what he or she have done?

Problem Impact

An another critical component of understanding the project’s current situation is to understand the extent of the project and how the project’s failure to meet expectations is impacting the business. Project failure has a cost to the business and understanding that cost can assist in creating a meaningful response to bring the project back on track. Some questions to consider:

  • What is the impact of the project problems to the business?
  • Where should the project be now in terms of progress?

Additionally, understanding the extent to which the project is off course. In order to make corrective actions, understanding of the projects current deviation from plan is important to understand. Some questions to consider:

  • Where is the project now in terms of percentage complete?
  • Is there are metric available on Earned Value against Planned Value? Are these figures reliable?

Review the Original Objectives and Scope

Before taking corrective actions on a troubled project, a project manager should understand the project’s scope and deliverables. The project charter outlines the scope and deliverables for the project as a starting point, but changes most often have occurred in the scope. Project scope and deliverables might no longer be valid because of changes in the business. Some questions to consider:

  • Are the original Objectives and Scope of the project still valid?
  • Have the objectives and goals of the project changed?
  • Has the scope changed enough to significantly derail the project?

Review the Project Performance to Date in Detail –

List all of the key deliverables, milestones and assess:

  • Where should they be in terms of completion / delivery?
  • Where are they (status)actually in terms of completion / delivery?

Assessment of the original plan against current status in detail is critical, and there is no shortcut to completing this assessment. The assessment will \will take time, and the devil is in the details. There can be a huge number of deliverables in a large project, so this process is not for the faint-hearted.

It is recommended to be as binary (yes or no and complete or not complete answers) as possible during this review so that the results are honest. It is important to note that you will not make any friends during this process so try to take the emotion out of discussions by focussing on the facts. Some clients may hire in external resources with no personal history on the site in order to get to the facts and remove the possibility of any personal influence.

If a task is late or has had to be repeated has this resulted in an increased cost? Is this substantial? How is this being measured on an hourly/daily basis?

The resulting report from this review process will arm you with the factual data from which you can get to the root cause of the problem(s) and re-plan the project to get back on track for a successful outcome.

Project Risks

Review the original project risks to assess if they are still valid. Have the project risks been updated? Are there any new risks that need to be assessed? How will they affect the project? Have any of the original or new risks been realized? Have they had any impact on the project delivery?

Analyze the Data

Are there any patterns emerging from the review data. Using these results – look for patterns such as consistent issues with departments, people, vendors – that are consistently late or repeating tasks not completed correctly.

If there is an obvious pattern with a delivery and this is identified back to a person or a department, look for further evidence. Is the person experienced enough? Are they the right person for the job? Is there role in the project clear to them and everyone else? Are they doing other work that is preventing them from focusing on project work? Are they capable of the work assigned to them? How was this person or department originally assessed for capability? How was individual performance being monitored?

Are there other factors influencing delivery -e.g. personal behaviors, interdependent service inefficiencies, process issues, system issues, late equipment/software material delivery, procurement issues?

Are operations based resources being allocated enough time to work on the project? Has the client prioritized the project to reflect the required delivery times?

The purpose of this analysis should not be a witch hunt but an honest review of the data recorded in order to get to the real issues.

Do not overlook here to review the controls processes if they fail to capture an issue early enough to control the issue.

Report

Produce a report of your work that should include but not be limited to:

  • Background to the Problem
  • Findings
  • Results
  • Conclusion
  • Recommendations

Utilizing the data that you have collected and the conclusions that you have drawn, based on evidence -communicate the results and recommendations to your main point of contact at the client site on a 1:1 basis.

Present the raw facts to them on confidence and seek their advice on:

  • What would they prefer to do next?
  • How should this information be released to the wider audience?

This will be a good measure of the politics on site and how it should be managed. Remember this is the client’s choice on how they wish to manage the situation.

Although it is rare -it is not unknown for clients not to do anything following such an investigation as corporately the “right thing to do” would step on too many toes and may not be the politically correct course of action.

Take Corrective Action

In order to get the project back on track you will need to do the following based on what you have learned:

  • Define the Scope
  • Perform a Project Risk Assessment
  • Re-plan the activities with new milestones
  • Re-work the budget to reflect the new plan
  • Select the project team (typically some original -some new members)
  • Create a proposal outlining the Project be delivered and what will be different his time in order to prevent a recurrence of issues.
  • Make this presentation to the key stakeholders and seek support and approval to move forward.
  • Kick off the project and implement the necessary controls.

Pilot an Agile Project in Your Organization

Written by Evgen Domch on . Posted in Articles. 8 Comments on Pilot an Agile Project in Your Organization

As Agile is more suitable for software development, but not all companies are ready to move from Waterfall to Agile.

Waterfall has served many projects well and is still considered as a good methodology. It is used by many companies in their day to day work. Agile is a relatively new methodology in development with many advantages, but it is not always suitable for all project types.

Let’s elaborate an approach to starting an Agile Pilot project in your organization.

Select a Project

There are several important factors to consider when selecting a project:

  • Project size must be at least 4 weeks. This time is optimal to form a full feedback and understanding of the methodology itself. The optimal maximum size of the project is 12 weeks.
  • The project should be important, but not critical. Since this is a pilot project, it is very important to consider a project without mission-critical deliverables or outcomes with a clear and specific expectation of project success.
  • Stakeholder involvement is important to involve in the project the Project Manager, designers, developers, testers, and Business Analysts. Ensure feedback from all participants is elicited and documented.
  • The project selected should go through all stages of development such as initiation, discovery, concept, design, analysis, development, testing and implementation. This gives participants a broader perspective of how Agile works from the beginning of the project to the end of a project.

Chose a Team

Perhaps this is the 2nd most important element in the first project experience is team member selection. Team members should have the skill sets and experience to be able to deliver the project outcomes and deliverables. Beginner or novice team members will have little knowledge of the potential solution will be a detriment to completing the project successfully for the first time in an Agile environment.

The team should want and be willing to implement a project using the Agile framework. Enthusiastic teams are more likely to be successful in implementing an Agile project for the first time.

Team members should also have a basic understanding of the Agile and Scrum methodologies or have used Agile and Scrum methodologies in a previous organization or role. Be careful to have a majority of team members with real experience with Agile on the pilot project. They will be able to help less experienced team members on how Agile and Scrum operates.

Formation of Roles

The next step will be the formation of the roles in the team. Key roles for an Agile team are:

  • Product Owner
  • Scrum Master or Agile PM
  • Development Team
  • Business Analyst or Customer

These roles are divided into 2 groups. Client Side and Technical. The client side, namely the Product Owner and the BA, are responsible for the creation of requirements and form them into user stories. The goal of Product Owner is to provide “Just enough” information to the development team so that they would be able to begin work on the product within the sprint.

User Stories and Acceptance Criteria

An early stage of planning is “Road Map” or sprint planning. It is necessary to plan each sprint based on the estimates provided on what it would take to complete the user stories. Since this is the first Agile project — accuracy is not what you should emphasize. Be mindful that you are still constrained by the length of the sprint. Your first few sprints will most likely have very inaccurate estimates for user stories. This will result in the first few sprints not accomplishing all the user stories expected.

Planning consists of taking the desired functionality and creating user stories to support them. Each of the user stories should have a specific set of acceptance criteria. This ensures the definition of “done” is clear to the team.

A user story is an instrument of functional description which is typically stated in the following fashion:

As a _________ I want to _________ So that_______

Acceptance criteria describes specific functional requirements that will be accepted by the business for the user story. and show specific steps to achieve the result. Acceptance criteria are typically constructed in this manner:

Scenario: Login

Given: I am on the Log in page, and the login ID and password fields are displayed
When: I am able to enter my login id and password
Then: the login button is displayed and available for me to click to start the login process

Prioritization of User Stories

Prioritization of user stories is an important part of any Agile project. As sprints are very time constrained and this is a pilot program expectations need to be set that not all user stories may be able to be delivered within the expected timelines. Prioritization of user stories will allow those user stories with the most business value to be worked upon first. Sprint 0 planning should take the prioritization into consideration when planning which user stories are placed in specific sprints.

Estimating User Stories and Acceptance Criteria

Once the user stories and acceptance criteria are created, then we are ready to estimate. Typically a T-Shirt size system of XS (extra small), S (small), M (medium), L (large), and XL (extra large). Each user story and acceptance criteria are estimated using this approach. As a pilot project, you will encounter estimates that are not very accurate. This will result in the early sprints of an Agile pilot project to not deliver all the expected user stories for a sprint.

Once the user stories and acceptance criteria are sized, they are slotted into sprints. This activity occurs in Sprint 0.

Getting to Zero

Sprint Zero is a very important event. In this sprint several things will be determined:

Sprint size is determined. Sprint size is the duration of all sprints in the pilot Agile project. All sprints should be of equal duration. Be aware that as a pilot Agile project your durations may be a little longer (such as 3 weeks) in order to assist in team members in learning the Agile process more fully). Typically sprint durations can range from 2 weeks to a month. Pick a duration that makes sense for the team and will result in incremental deliverables that will give the team a sense of success.

Plan each sprint by aligning each user story and acceptance criteria into a specific release based on its priority. Be careful not to overfill a sprint. Realistically align user stories with sprints based on their estimates. As always beware your estimates may not be very accurate. Start the first couple of sprints with a smaller amount of user stories to give your team the time to learn the Agile approach to development.

Once user stories are assigned to sprints, review the tasks needed to complete each user story to ensure the tasks can be completed in the sprint. Be aware that some task may require the efforts of resources that are outside of your team. Where ever possible ensure the tasks that are performed outside of the team are completed prior to the sprint starting. An example of this would be a DBA. A database request may take your organization several weeks to complete and implement. Trying to squeeze the database change into the sprint would result in not being able to complete the sprint fully. Instead, have the DBA request completed before the sprint started to developers can focus on the sprint without having to wait for external resources to complete tasks for them.

Starting Up

Schedule the daily stand-ups. Be sure all team members understand the daily standup and the purpose of a stand-up meeting. Put a 15-minute meeting on your team members calendars (hopefully schedule in the same room) every day with each team members covering these topics:

  • What I did yesterday
  • What I will do today
  • Do I have any problems or concerns

The scrum master will lead these meetings. Bring a timer. The is 15 minutes in length and time is of the essence. This is a problem-solving meeting. When problems are identified, immediately ask who needs to be involved in determining a solution for that problem. Then have those individuals tackle finding a solution OUTSIDE of the meeting. The amount of time per team member depends on the team size but typically 2-3 minutes is given to each team member.

Interaction with team members is important. Due to time constraints of the daily stand up and sprint a lot of pressure is put on the new Agile team member. Be sure to give them opportunities to discuss their experience and be available to offer solutions to situations that are encountered.

Acceptable Product

Acceptance criteria were established for each user story. As each user story is completed, the acceptance criteria for that user story should be validated. Make sure the team understands that user stories must be validated by the team by executing the acceptance criteria.

End of the Sprint

A sprint review and demo are conducted at the end of the every sprint. This reviews the user stories that were completed ensures acceptance criteria has been met.

At the end of every sprint is a retrospective to reveal lessons learned. This is important as this pilot Agile project will need feedback to improve future efforts and processes to help the pilot Agile project be more successful over time. An hour meeting with all teams should answer the following questions:

  • What did not go so well?
  • What still puzzles or doesn’t make sense to us?
  • What went well? What things should the team keep doing?

A good thing to keep in mind is ending this meeting a positive light. Focus on things that didn’t go well and move into things that went well. This leaves the team members with a positive impression at the end of the meeting.

The leader for the Agile project pilot will need to take steps to improve areas where things didn’t go well or areas that don’t make sense to the team. Always ensure follow-up is performed with the team on items brought forward that need improvement.

Do not try to solve the problems identified in the retrospective meeting. Assign teams members to investigate and get back to the group at a later date.

In a Nutshell

This article elaborates a very high-level set of tasks for piloting an Agile project. The structure and readiness of your organization’s leadership to use the Agile methodology should be explored deeply before starting an Agile pilot project. In setting senior leaders expectations, it is important that senior leaders have a complete understanding of how the Agile Mythology operates. Setting the expectations of senior leaders for the pilot is critical to ensure it has a good chance of success.

Good luck on your Agile pilot project!

Project Failure: A Catalyst for Success

Written by John McGrath on . Posted in Articles. 18 Comments on Project Failure: A Catalyst for Success

There have been huge advances in project management in the last 20 years, but the elephant in the room is the issue of Project Failure.

Success rates are not improving and the metrics surrounding project failure have been disturbing for decades — at least 50% of projects do not deliver on their promised results.

These failures can cost hundreds of thousands of dollars – and into the millions – for very large projects. Also the lack of program management can cost companies millions of dollars in cost deviation. This is important because, over time, the value of your corporate brand and enterprise success rate are related.

The causes of project failure are well known, predictable and have not changed over several decades. Projects and organizations continue to be impacted and do not seem to be able to create the environment in which projects can succeed. It would seem that organizations have a fundamental inability to learn the lessons of project failure.

There are many causes of project failure and every failed project will have its set of issues. Sometimes it is a single trigger event that leads to failure, but more often than not, it is a complex entwined set of problems that combine and collectively result in failure.

This inability to learn from project failure is across all industries and sectors and includes many of the most successful organizations on the planet. The financials of failure are staggering and a complete industry has emerged to address the reasons for failure, which are as predictable as the next dawn.

We also often realize with the benefit of hindsight that most failed projects were exhibiting early warning signs and there was sufficient opportunity to respond but the signs were not acted upon in a timely fashion.

The definition of success or failure is not as straightforward as was once imagined. We are now very aware that project success cannot be adequately defined within standard parameters: completion within time, cost and performance expectations.

Cost and schedule performance are still important but the perception of project success now also includes:

  1. Meeting the functional or technical specification
  2. Meeting the business case
  3. Engaging with stakeholders

Failure is not comfortable to embrace but it can often be a catalyst for success, especially if project failure comes early in product development and is accepted by all involved as a way forward.

Research shows that about 50% of projects fail because of the lack of visibility over the entire spectrum of the project management process. Take, for example, software development or the creation of a new medical device. Management of the project may involve numerous teams, each dedicated to a certain aspect of the process. However, they are operating in silos, each with its operational style and strategy for success. If these teams do not communicate effectively, the result is often a failure to deliver a successful product, often due to cost overruns or relevance to the target market.

Why Projects Fail

When projects fail, hindsight often reveals that issues were bubbling up – but ignored. These issues may include a lack of hands-on project sponsorship, team leadership, lack of resources, inability to manage change, and lack of communication. Lack of communication is the basic culprit because, without communication among project teams and leaders, there’s no clear visibility into the development process and thus what we call no “single version of the truth.”

However, when a failure occurs early in the project lifecycle, it is because of clear communication among project teams, leading to that single vision of truth. Early failure triggers positive change management and the revamping of strategies, providing a window to a successful result before massive dollars and precious resources are needlessly spent.

Effective execution needs effective planning, which includes not only tools but most importantly, human interaction. This is the art and science of project management – tools and people skills that give total visibility to the entire process.

Developing Hybrid Methodologies and Organizational Procedures

Often organizations think they can just apply off the shelf methodology – lean, six sigma, agile – and just simply apply them to the organization. While these are all good standard practice methodologies, by recognizing the relevance of each and applying them to internal procedures and the organizational toolbox, these ‘good’ methodologies become best practices – and thus a hybrid approach.

There is no magic wand for good practice project management. It takes consistent effort, applying lessons learned from other organizations or international best practices. It takes the entire team – from the C-Suite right down to the project level – to drive success. Everyone must be involved.

Project governance needs senior management support and they must understand the basic tenets of project management and the specific role that they play in the strategy. This group becomes particularly important when change management is necessary. Change rarely occurs horizontally but must come from the executive board, which often gives the go-ahead to drive that change to all project teams. It is important, therefore for the executive team to get on board with the project management scenario at the earliest stages and meet regularly with the teams. This provides the harmony and synergies necessary to manage risks, institute necessary strategic changes, and eliminate unshared silos of information.

Creating a Structure for Success

Leading the effort should be an enterprise project and portfolio management approach, which provides structure (including gate reviews and milestones), standards, reporting procedures, training and team management. A Project Management Office (PMO) can be the backbone of a successful project management approach by assuring that project delivery is managed in a controlled way. Its focus is:

  • Governance – guidance that decisions are made properly – by the right people with the best information, audits or reviews that assure accountability
  • Transparency – accurate information to support the “single vision of the truth.”
  • Quality Assurance – eliminating bureaucracy, providing training and mentoring – making it easier for teams to do their jobs.
  • Eliminating redundancy – creating a knowledge base for templates, best practices and lessons learned.
  • Reporting – management of documentation, project history, and risk analysis.

While structures may differ depending on the organization, there does need to be a central point of management that fits easily into the organization’s culture, takes into account the resources available and is the guardian of enterprise portfolio management tools. There may be one or more experts in the PMO who supports project managers and their teams with project management software.

This office may also manage a portfolio level dashboard that provides a type of helicopter review of the project as it moves forward. This dashboard plays an essential role in transparency, providing a comprehensive look at the myriad of details that are involved in project success and how each of those areas is moving forward – or not – in seeking achievement of the end strategies.

Setting up a PMO can be a large undertaking and a considerable upfront investment that must eventually prove its worth, which means a thoughtful approach is the best one. Depending on the time available, it may be helpful to begin the process slowly offering key services and building up as necessary to support projects in the pipeline. This is not unlike the approach that is taken in developing projects by phasing in activities to gain buy-in by stakeholders and identification of problems early before they become unmanageable, i.e. embracing failure as a way to move forward with a more successful strategy.

Gaining support from the executive level, as mentioned previously is key, but only one part of the equation. Seeking support from stakeholders is also critical. Clear communication as to the benefits of the office and its tools is a must and can be delivered in team meetings or one-on-one interactions with important influencers. Moreover, if there are stakeholders who do not seem to agree with the way forward, a special effort needs to be made to create a positive attitude for the benefit of the entire team.

Clear processes are essential but the recognition that these processes may change over time in response to new information or direction reveals the need for a focus on change management. Rather than a flurry of changes that users need to absorb on an ad hoc basis, setting up a recurring plan for review of processes and amendments eases transitions and makes for a smoother implementation.

Finally, stakeholders need to be aware of the long-term benefits of the office but it’s also helpful to show immediate benefits of the PMO to the organization. Depending on the complexities of the projects, it may take some time to the assess the full value of the office but there are a few ways to show progress. For example, introducing templates to standardize processes makes it easier for users to report their activities and gain visibility. Gaining buy-in from project managers on software solutions also can help elevate a positive view of the PMO.

Early Failure Builds Success

Early failure builds a pathway to success. However, early failure can only occur if a strong transparent PMO is in place that focuses on leveraging organization tools, dynamics and culture and that recognizes the importance of human interaction. Communication, transparency, and clear direction are key to a successful implementation that’s built on knowledge transfer and pipeline visibility.

About the Authors
John McGrath, PMO Consultant and Project Management Lecturer at Dublin Institute of Technology and Philip Martin, Founder and CEO of Cora Systems

8 Things You Must do Better to Make Better Decisions

Written by Richard Lannon on . Posted in Articles. 16 Comments on 8 Things You Must do Better to Make Better Decisions

I have been thinking lately about what it takes to make decisions. Just recently I was presented with a situation where some major decisions will need to be made.

Ones that impact changes in business and careers focus and could mean going into a whole new direction. So you have to make the best decision with the information at hand for your organization. From that perspective I think there are eight things you must do to make better decisions.

1. Invest in decision making skills.

This is something that holds true today as it did ten years ago or more. I see this as a foundational skill that people need to learn, practice and apply. There are many approaches or methodologies that can be applied in the decision making process whether you are a traditional organization, project based, a committee environment or driven by the board of directors. Often the fundamentals of decision making are missing. Look at the environment and create an appropriate decision making structure.

2. Create time to think ahead.

Time, time and more time is something we don’t have. It has become a luxury that most people can’t afford. Yet making good decisions requires time to reflect and look at the road ahead. What if you are considering changing careers and decide to go in a whole new direction? This is a big decision. This applies to a business venture also. Change and transformation are difficult to do on a whim, often you are required to think and plan ahead. But don’t over think long term plans as things change around you quickly.

3. Know who you serve.

This is an important point to answer. I know a lot of business leaders and professionals who I am completely confident in their ability to get the job done, to move forward and make things happen. But, they lack an important insight and clarity of who they serve. Decision making is a whole lot easier if you know who you serve whether it is a specific target market, an organization or something else. I think it provides opportunities to make mindful decisions and improve innovation and creativity in solving problems due to clarity and focus. It does not matter if you upset the market because you know who you serve.

4. Question everything, especially the business.

I often get asked how I would approach a specific problem. I am in a meeting and someone sets up a scenario and wants to know my approach. Any good business analyst, trainer or consultant will know the basics; define the problem, evaluation solutions, implement the approved solution, and measure the results. Part of the process is to question the business model. Recently I had this happen in a meeting with an executive director. I was presented with a question and responded but within that response I placed questions to better understand the business model of this organization.

Turns out they are looking for a change and the business model is suspect. It is always good to question, even when answering.

5. We can all think in a straight line.

Straight line or linear thinking is the a, b, c, of decision making. With so many organizations talking about innovation, creativity and being intentional I wonder what’s the point. There are many theories about what approach you should take. I still think the best approach to decision making and initiative integration is a mix between predictive and adaptive planning. These two approaches provide the best of both worlds, and when blended, often provide an organization an approach that works beyond the mere linear.

6. Create a story around decisions.

Life is a story and you write it yourself. With every decision there is a story that comes from people discussions, thinking, making assumptions, determining impact and communicating the decision. Wouldn’t it be great if you could create a decision narrative that is beyond the old boring business report? People want to be part of the decision story that makes a difference thus bridging organization gaps. You should create decision making stories.

7. We are all moving at the speed of a click.

Over decades my career has been part of the professional consulting and service economy which has accelerated at lightning speed in recent years. When I look at the professions’ value stream I think we need to make better decisions around the downstream business environment. Clients no longer just order or buy stuff they engage now in a very different way where it becomes difficult to determine the ROI on business activities. Margins wither as the need to provide valuable free content increases making business decisions a challenge to make. No matter the business you are in, the accelerated service economy is impacting your business.

8. Find a tool, reduce your risk and get costs under control.

The strategic business analyst looks at the past, present and future of a strategic plan and approach and use financial analysis of NPV, IRR and ROI within your business case. But it is important to go further and look at risk with uncertainty analysis. This is something that I learned over time from various economic adjustments (ie: dot com bubble burst, corporate and accounting scandals, subprime mortgages issue, and resource industry collapse) I think uncertainty needs to be determined better. Business intelligence and uncertainty reducing tools can be used to assist in this analysis. My point, the business analyst can play an important part in helping organizations make decisions through embracing uncertainty analysis approaches and tools to help deal effectively with unpredictable times.

Final Thoughts

Big decisions are tough to make, especially when you have invested so much time and effort on your business or focus area. When you work in a space where you are building skills and helping businesses define their future, you start to realize that there are certain truths that exist. One truth, everybody wants to survive and be around a long time. The second truth, that there is always a purpose that needs to be achieved. Third truth, good decisions and core competencies take you a long way to creating a profitable future thus achieving the first two truths.

7 Steps to Financial Approval of Your Project

Written by Shreenath Sreenivas on . Posted in Articles. 14 Comments on 7 Steps to Financial Approval of Your Project

You’ve been assigned as the project manager for a project that MUST deliver a critical IT system to avoid legal and compliance repercussions.

You’re told “Your next step is to secure financial approval. Since the total internal funding is limited this year, the Executive Board (EB) is scrutinizing several other high priority portfolio projects, and they all heavily compete with your project. So, get this moving quickly!”

Related Article: How Senior Executives Unconsciously Disrupt Projects

What do you do? Where do you go first?

Below are 7 steps to follow to get financial approval of your project.

1. IDENTIFY AND ANALYZE KEY INFLUENCERS AND THEIR NEEDS

Never assume what people’s needs are! Your first step is to promptly identify and reach out to key influencers to gain insights into the organizational climate, business-IT strategy, approval process and investment appraisal factors.

Also, devise a plan of action to deal with each influencer.

This requires a strong implementation of the PCPM methodology that’s described here.

2. STUDY THE ORGANIZATIONAL CLIMATE, BUSINESS-IT STRATEGY & APPROVAL PROCESS

Organizational Climate: To deliver better outcomes in high growth areas of business organizations transform dynamically and rapidly as the world changes around them. They are constantly looking to improve efficiency and efficacy by reaching new levels of functional excellence.

Focus can shift towards increasing revenue or optimizing cost. In such scenarios, internal funding for major, vision-led, wider organizational initiatives may bypass departmental budgets and come direct from the Executive Board.

Watch out for how the organizational climate could influence the EB’s perception of your project alongside these wider initiatives.

Business-IT Strategy: Understand the current business-IT strategy. Be it application development and rationalization, infrastructure, sourcing or Lean IT. In some cases, implementing the solution quickly and within budget is the sole criterion.

Your job does NOT just end at just delivering the system. So, ensure that the system delivered is in line with the business-IT strategy.

Approval Process: Study the approval process well. If this is not well documented, ensure key influencers are in agreement as to this process.

Every missed step in the approval process could cost you time and money – unacceptable if you are entrusted with a constrained project.

3. ANALYZE THE BUSINESS NEED & ALTERNATIVES AND EXPLORE SYNERGIES

Business Need & Alternatives: This is where your business analysis skills will be helpful! Work with the business to clearly understand the business need and direction. If the business need isn’t clear, propose a review to bring clarity to the issue, even if it takes more time!

Explore all alternatives and their qualitative and quantitative benefits.

Sometimes inefficient or non-scalable solutions may already exist and in such cases doing nothing is also an alternative – don’t forget to list this as well!

Cross-Divisional/Portfolio Synergies: A disadvantage in large complex organizations is that divisions work in silos. The advantage, however, is you can likely find divisions doing similar things. Explore cross-divisional synergies and tap into them. There are benefits and risks – but in most cases benefits outweigh risks.  For example, you may be unwelcome to onboard another project due to strategic reasons, but you must try if it favors the organizational strategy.  PMs are sometimes unaware of what’s going on around them. Reach out to the PMO to learn of the other portfolio projects and programs. You may find synergies within the portfolio itself. Sometimes, it may involve moving funds between projects, re-scoping projects or even their cancellation in order to use funds more effectively for your project.Sreenivas 103116 1

4. DEVELOP A SOLID BUSINESS CASE & INVESTMENT STORY:

Solid Business Case: Develop a solid business case for top 3 alternatives – including quantitative and qualitative factors.

A common mistake is that project managers showcase what they would like but not what the Executive Board might look for. So ask yourself “What could the Executive Board be looking for to buy-in to my business case?” This may be a tough question to answer, but resolution comes with experience.
WBS, Project Budget & Contingency Reserve: Not having a solid WBS is the biggest problem. Build on one before you estimate your costs and the overall project budget.

Don’t include random contingency reserves in your budget (e.g. as a % of the overall project cost). The EB will have no tolerance for contingency reserves unless they’re an aggregate of concrete cost estimates required to implement risk responses for known risks. So, implement risk management diligently!

Investment Story: Don’t jump into building an investment story before you understand the key investment appraisal factors – some of which are below:Sreenivas 103116 2

There may be levels of uncertainty regarding the availability of funding. Long-term secured funds will be committed to longer, high-priority programs that showcase positive NPVs. However, legal or compliance projects may or may not always have a positive NPV. However, try to build on one – challenging, isn’t it? Give it a try:

Quantitative:

  • Payback: Simplest technique.
  • Net Present Value (NPV) & Internal Rate of Return (IRR): Higher the NPV or IRR, the better.
  • Accounting Rate of Return (ARR): Higher the ARR, more preferred.
  • Adjusted Present Value (APV): APV overcomes the shortcomings of NPV and is used for a highly leveraged project.
  • Total Cost of Ownership (TCO): Lowest TCO offers the best value for money.
  • Real Option Analysis: Real option analysis considers and values the various options that managers would have while managing their projects in terms of increasing cash in-flow and decreasing cash outflow.

Qualitative:

  • NPV with Assumptions: Calculate a financial value by applying a series of assumptions. E.g., include assumptions about the numerical impact of increased morale on staff turnover and the estimated costs of recruitment to showcase benefits. Examples of non-financial factors that can be translated to NPV with Assumptions are:
  • Reduced maintenance costs due to out-of-the-box industry standard solution.
  • Productivity time savings; no FTE reduction.
  • Potential to implement future business needs without further investment.
  • Relationship improvement with suppliers/customers reducing procurement overhead.
  • Anticipating and dealing with future risks and threats, e.g. protecting intellectual property against potential competition.
  • Scoring Methods: Compare the subjective value of benefits e.g. degree of coverage of requirements, the fit of offered solutions, etc.

5. DRAFT A FIRM STATEMENT OF WORK (SOW)

Draft firm SOWs encompassing all aspects of the procurement – top things to consider can be found here.

The EB will challenge you to re-negotiate on costs/time. So, negotiate in the first place and present documented evidence of the Initial vs. Negotiated costs/time. Involve sourcing and legal teams at every phase – they’re crucial in supporting you with securing approval.

6. PRE-ALIGN WITH KEY INFLUENCERS:

So, having to prepare and present your case to the Executive Board can make you nervous and cause what I call the “Executive Presentation Syndrome” – similar to stage fright. To overcome this, find out what the EB needs to approve your project.

If you’re unsure:

  • Don’t hesitate to learn from your colleagues lined up for approval or to those who have had their projects approved already.
  • Re-align with each influencer on what they expect from you – that will help them approve your project without surprises on the big day.

This is difficult in today’s global virtual world, but again, PCPM will help. Anticipating in addition to learning is half the battle!Sreenivas 103116 3

The Executive Board would always like to see tangible factors. Failing to deliver tangible benefits can result in you having to go back and forth with the Board in order to make your case stronger.

Every approval cycle involves multiple reviewers and approvers. Communicate with them on when you intend to submit your project so they can make themselves available or deputize someone to approve your project if they are not available.

7. BE VERY WELL PREPARED FOR THE BIG DAY:

Have a Killer Presentation Ready:

So then, are you ready to present your case to the EB? If not, seriously consider requesting them to push back your presentation to a future date. NEVER go into a meeting unprepared – you’ll lose your credibility and reputation!

When you’re ready, here are a few tips that will help you breeze through the approval process.

Prepare a killer “10-20-20” PowerPoint slide that has no more than 10 slides, takes no longer than 20 minutes and has no text less than 20 point font. Remember that a picture speaks a thousand words!

Tips for the big day:

  • Come early
  • Prepare a 15-word summary
  • Put yourself in the audience and present accordingly
  • Don’t read the slides
  • Slow down
  • Listen
  • Project your voice
  • “That’s a good question”: If you’re not ready to answer, offer to come back.
  • Don’t breathe out or use words like “hmm” or “ah”; repeat the question to ensure you’ve heard it right and this will give you time to work your brain to answer
  • Don’t apologize unnecessarily
  • Apologize if you’re wrong
  • Have fun! Sounds impossible, but with a little practice, you can inject your passion into your presentations. Enthusiasm is contagious!

Finally, don’t forget to thank everyone and celebrate your success!