In Part IV, we continued our discussion of Project Assurance, asked how a Project Assurance Specialist insures true project success, and asked why only an outside Project Assurance Specialist (PAS) can insure this success. We noted that the PAS uses collaborative intervention to insure success, overviewed the three phases of a collaborative intervention, and stated that it could only be done by an outside PAS.

Today we will discuss why the Project Assurance Specialist has to be an outside expert, and we will do so by reviewing ten primary reasons, as found in many articles and books on project failure, on why projects fail and why it takes an outside PAS to prevent this failure.

Consider these ten common reasons projects fail.

• Lack of top management commitment
  Stakeholders inside the organization often don’t understand the level of commitment required and often have a skewed perception of how committed an individual in the organization really is to the project. An outside expert comes in with a clean slate and an uninfluenced view.
• Unrealistic expectations
  An outside expert has a clearer picture of what is and is not reasonable as that expert has a broader view of the market, solution providers, and off-the-shelf solutions.
• Poor requirements definition
  Since it will be the first acquisition of a Supply Management solution for many organizations, many organizations have no idea what constitutes a good requirements definition. An outside expert, on the other hand, will not only know what does, but what absolutely has to be addressed for project success.
• Improper Package Selection
  The selection needs to address the real needs of the organization, and not the perceived needs, and the provider needs to be one that can grow with the organization.
• Gaps between Software and Business Requirements
  If you don’t really understand what software is needed to effectively satisfy a business requirement, it is almost impossible to avoid gaps — especially when you don’t really speak the language of Supply Management solution providers. An outside expert, who does speak the language, can help insure that there are no gaps.
• Inadequate Resources
  Since most organizations have never implemented the system that they need, they have no real understanding of what resources are really needed. An outside expert will have this understanding.
• Underestimating Time and Cost
  It’s a good rule of thumb that software-based solution projects always take longer and cost more than you expect, even with a best effort. But how much longer and how much more? Only an outside expert with experience in the type of project you are going for can guarantee that your estimate will be in the ballpark.
• Poor Project Management / Lack of Methodology
  The truth is that you can’t manage what you don’t understand, and whatever you miss in strategy, planning, and design will come back to bite you in the @ss before the project is over — unless, of course, you have a methodology that insures nothing crucial is overlooked and all issues are identified and mitigated away (or at least managed) as they arise. Only a Project Assurance Specialist can identify all these key points that your internal team will miss.
• Underestimating Impact of Change
  It’s hard to assess the impact of something you’ve never done — and with solution providers constantly whispering calming assurances into your ears, it’s easy to underestimate the impact (especially if you have a team that is adverse to change). An outside expert can not only peg where you are in terms of process and technology maturity, but where you are in your ability to manage change.
• Lack of Training / Education
  How many times have you heard “it’s so easy to use, it teaches itself” or something similar from a solution provider. While this may be typically true for the technically inclined, it will not be true for those who are not technical by nature. Nor will it be true for the advanced functionality or tasks that are not performed daily. Training and education will be required, and an expert will be needed to advise you on how much you will truly need.

There are other reasons, and some are clearly explained Prinzo’s No Wishing Required, but these should be enough to convince you that assurance is often critical to project success, especially if the project is complex or it is the first time your organization is undertaking such a project. You have to remember that your PMO (Project Management Office) has expertise in project management, not project evaluation, and, being internal to your organization, can’t really bring the true objectivity an external expert can.

That’s why you need an Assurance Specialist to check up on you at key points. Chances are, if your PMO is on its game, the project will be going rather well when the specialist checks in at each stage, but chances also are there will be little things missed here and there which, if not managed, could morph into big ugly monsters down the road.

Project Assurance is like insurance for your project. A small premium that offsets a big loss down the road. You might be one of the organizations that don’t need it, but considering it typically costs so little compared to the overall project (management) cost, can you really afford not to buy what works out to rather cheap insurance? the doctor doesn’t think so, and believes you shouldn’t either.

In Part II we related Project Assurance — a comprehensive, proactive, and preventative methodology that goes beyond IV&V to address strategic project issues in a proactive manner so that potential issues are identified and mitigated before they become problems — to your Supply Management Solution Acquisition project and stated that you needed an outside Project Assurance specialist in order to achieve true project success.

So how does the Project Assurance Specialist insure true project success and why can it only be done by an outside Project Assurance Specialist? We will address these issues in this post.

How does the Project Assurance Specialist (PAS) do it? As made clear in Rob Prinzo’s No Wishing Required, the PAS uses collaborative intervention when conducting the health assessments at each of the six critical project points.

Collaborative Intervention is a process used by an Assurance Specialist that attempts to avert disaster by identifying the warning signs that problems are on the way and that the project could be in jeopardy if they are not addressed and the problems not mitigated. A collaborative intervention consists of three primary phases:

• When Are We?

  Where is the project in the project’s lifecycle, what types of issues are likely to arise at this time, and what should the Assurance Specialist keep an especially watchful eye for.

• What Has (Not) Been Accomplished?

  An objective top-to-bottom evaluation — focussed on what to look for in an effort to insure project expectations are aligned, resources and scope are appropriate, and the probability of success is high — is conducted and attempts to identify:

  • what are the real issues
  • what are timeframes that are realist
  • what can be done to align the work streams
  • what the indicators don’t tell us
  • what expectations are (still) realistic
• How Can We Address the Issues That Have Been Identified?

  The findings of the assessment are presented to a cross-functional collaborative intervention team and the PAS works with the team to identify the root causes of potential issues, mitigations to deal with the root causes of the potential issues, and the implementation plans to implement those mitigations.

Why can this only be done by an outside Project Assurance Specialist? Return for Part V.

In Part I we introduced you to the concept of Project Assurance, the specialized discipline and practice involving independent and objective oversight, specialized experience, and audit skill to assess risk, finance, accounting, compliance, safety, and performance for any major capital expenditure (Source: Wikipedia) that is designed to minimize the risk of projet overruns and failure.

In Part II we noted that Project Assurance is a comprehensive, proactive, and preventative methodology that attempts to go beyond simply addressing tactical issues brought up in methodologies like Independent Verification and Validation (IV&V) to address strategic issues in a proactive manner so that potential issues are identified, and mitigated, before they become problems. We also noted that Project Assurance involves conducting a health assessment at six critical points of a project to make sure that the project is on track, the project team is aligned, and the project is still likely to complete on time and on budget. We also described these six health assessments and when they take place.

In this part we relate Project Assurance to your Supply Management Solution Acquisition project and how an outside (Project Assurance) Expert can keep your project on track and your risk of failure or excessive cost-overruns low. As with the last post, we’ll take it in phases.

• Strategy (Expectation Management)

  As Supply Management is still an emerging discipline in many organizations, where each CXO and stakeholder will have a different understanding of Operations, Procurement, Logistics, and what current Supply Management Technology will have to offer, each team stakeholder will have a different expectation of what the outcomes of the project will be. These expectations will need to be aligned and managed before the project continues. The Project Assurance Specialist will need to make sure expectations are suitably aligned and that the goals and timelines are realistic before the project succeeds.

• Acquisition (Close the Procurement Gap)

  The RFP responses received by the organization will be thick, slightly confusing, and full of promises — not all of which the vendors will be able to keep in the required timeframe. Only an outside expert, with knowledge of the space and the solutions and what to look for, will know how to evaluate the responses against the RFP, and the strategy that resulted from the first phase.

• Planning (Align the Troops)

  Once the vendors are selected, and before detailed design (which will specify which parts of the out-of-the-box solution will be purchased and what custom extensions and integrations will be needed), the project is planned. Due to a lack of understanding within the organization of what is really required to effectively design, implement, and train users on a new platform, some organizations will accept a vendor’s overly ambitious timelines while others will add unnecessary padding. And most will overlook the indirect impacts of adopting a new solution and the secondary processes that will be impacted and that could be impacted in a good way. A Project Assurance Specialist will be able to identify these process and make sure that all of the processes that should be addressed are indeed addressed.

• Design (Delineate the Design Disconnect)

  Vendors, especially those paid by the consulting hour, will often want to overdesign a solution while buyers, who will want to minimize the cost, will often try to strip down the design too much. The right balance has to be struck, and the design that is accepted has to meet all of the core requirements for project success. A Project Assurance Specialist can help the organization find that balance.

• Development (Acceptance Evaluation)

  Does the implementation fully implement the design and meet all of the organizational requirements? Is the integration with the core systems complete? Are the switch-over plans sufficiently thought out and are there contingencies if things go wrong? And are the training plans in sync with both the solution that has been implemented and the average technical proficiency with those being trained? An outside Project Assurance Specialist can help the organization answer these questions and put the stakeholders’ minds at ease.

• Testing & Training (Transition and Acceptance Streamlining))

  Was the testing comprehensive and were all of the key test cases successful? Is there enough C-Suite support to ensure that even the dissenters will be convinced to consent and that the cut-over will be smooth and painless? Are there adequate resources to execute the go-live according to plan? Was the education sufficient? Is everything a green light? Only a Project Assurance Specialist can give you an answer you can truly be confident in.

So how does the Project Assurance Specialist do this and why can it only be done by an outside Project Assurance Specialist and not an inside resource? Come back for Part IV.

In Part I we introduced you to the concept of Project Assurance, the specialized discipline and practice involving independent and objective oversight, specialized experience, and audit skill to assess risk, finance, accounting, compliance, safety, and performance for any major capital expenditure (Source: Wikipedia), that is designed to minimize the risk of projet overruns and failure.

Project Assurance is a comprehensive, proactive, and preventative methodology that attempts to go beyond simply addressing tactical issues brought up in methodologies like Independent Verification and Validation (IV&V) to address strategic issues in a proactive manner so that potential issues are identified, and mitigated, before they become problems. In Project Assurance, the organization, under the guidance of the outside Project Assurance expert, a projet health assessment is conducted at a critical point of each project phase to make sure the project is on track, the project team is aligned, and the project is still likely to complete on time and on budget.

So when are these health assessments conducted and what is looked for?

• Strategy Pre-Presentation

  before the business case is presented for funding and approval, a health assessment is conducted to insure that expectations and requirements are aligned with top management’s commitment; the key stakeholders are interviewed to determine their goals and reasons for approving the project, the cross-functional team is interviewed to gauge their take on the project, and the business case and project understanding is reviewed and compared to the stakeholder intent. Discrepancies are brought up so they can be addressed before they grow into full-blown issues.

• Acquisition Pre-Vendor Selection

  before vendors are selected and negotiations begin, a review of software and services options is conducted to determine if there are any gaps between the proposed software and services and the business case and core requirements identified in the first phase. In addition to a review of proposals against project requirements is a review of proposed resolution procedures to make sure anything that is missed can be addressed and any issue identified can be resolved.

• Planning Pre-Design

  after the initial drafts of the detailed project plan and change management plan have been developed to insure there is a strong methodology in place, that resources are adequate, and that time line and scope are realistic. All documents are cross-reviewed and research is conducted to identify potential issues that could arise in the project and to make sure that the plans address them or have mechanisms to address them should they arrive.

• Design Pre-Acceptance

  after the initial drafts of the System Design documentation to ensure there are minimal gaps between the software and business requirements, the organization understands the impact of the coming change, and there are adequate resources allocated. All documents are reviewed and cross-validated and suppliers are interviewed in addition to the implementation team to make sure the core understanding of the software and service requirements is consistent and the design document addresses everyone’s concern.

• Development Pre-Testing

  near the end of the phase to ensure project management methodology is (still) well in place, the impact of the coming change is being addressed, and the proposed education and training plans will meet user requirements and adequately cover the technology utilization requirements. The implementation is compared to the design, the training plans to the implementation, and the change management plan to the breadth of the impact. Project team members are interviewed for potential concerns and the current state is compared to the plan.

• Testing & Training Pre-Acceptance

  near the end of the phase to ensure top management is committed to the cut-over, there are adequate resources in place for the go-live, and the education and training provided has sufficiently prepared the users for the new system. Problems explode into disruptions if a project goes-live before they are resolved.

So now that we know when project health assessments are conducted and what these assessments entail, how do they help you? Come back for Part III.

Project Assurance, the specialized discipline and practice involving independent and objective oversight, specialized experience, and audit skill to assess risk, finance, accounting, compliance, safety, and performance for any major capital expenditure (Source: Wikipedia), is designed to improve performance, increase efficiency, avoid unnecessary cost, and, most importantly, minimize the risk of project overruns and failure.

Project Assurance goes beyond Independent Verification and Validation (IV&V) (Source: Wikipedia), which, while independent, is simply a set of procedures used for checking that a product, service, or system meets the requirements or specifications set forth for it. Project success depends on more than just getting the technical specifications right. Projects also depend on getting the talent right — as it is the people who will have to use the new system. And projects also depend on getting the transition right — if the changeover is not smooth, significant disruptions to daily operations can occur. And they depend on a 4^th “T” — tracery. Organizational success depends on selecting a superior strategy and seeing it through until the desired results are achieved (or the organization changes the strategy). Tracery, from the late Middle English, can be defined as a “delicate, interlacing, work of lines as in an embroidery” or, more modernly, as a “network”. Implementing a strategy requires effectively implementing all of the intersecting “threads” that are required to execute the strategy to success. If any one aspect is overlooked, the project can fail.

And, as pointed out by Rob Prinzo in No Wishing Required, unlike IV&V, which mainly comes into play during the design and development stages, project assurance is part of the project from initial planning through initial roll-out. And at each stage it goes beyond traditional IV&V because, unlike IV&V, project assurance is not only comprehensive, but proactive and preventative. Whereas IV&V focusses simply on tactical issues relating to the system, project assurance considers the strategic intent as well as the tactical delivery. Whereas IV&V takes a reactive approach to issues discovered during the review, project assurance takes a proactive approach and tries to identify issues, and implement mitigations, before they arise. And while IV&V focuses on problems (and their solutions), project assurance focusses on prevention. The idea is to create collaborative resolution teams instead of crisis response teams when potential issues are identified. This way the issues are mitigated before crisis response is required.

So how does Project Assurance work? When using Project Assurance, organizations periodically stop and objectively assess project failure points as they arise, typically with the help of an outside third party who can be completely objective in his or her analysis on what the project team is and isn’t doing well and what could cause failure later if not adequately addressed now. In particular, the organization conducts a project health assessment at six critical points in every project — once in each of the six initial project phases defined by the classic waterfall project methodology.

Precisely when do these health assessments take place and how are they conducted? Come back for Part II.