The Power of Phase I

The Power of Phase I

If you have been an IT leader for any length of time, it is in inevitable that you will have projects that fail. Let’s define failure as any project that fails to meet time, budget, or deliverable expectations. It is especially tough in the mid-market space since we are more likely to depend on vendors than our fortune 1000 counterparts, but no company is immune from problem projects.

One of the best ways I have found to reduce the inherent risk of project failures is to always think in terms of Phase I.


Phase I can be a proof of concept, an assessment, or a consulting engagement designed to discover and document requirements that can be used to reduce risk for the next phase of the project. There should be no expectation from the vendor performing the phase I engagement that they will become the vendor of choice for the next phase of the project – although it shouldn’t necessarily preclude them either. You just need to be careful that they are presenting you with unbiased information and not coloring or distorting the findings to sway the next phase in their direction.

The Stage-Gate Approach

Projects of any significance in terms of scope, impact, or investment, should never receive just one approval. Multiple stage-gates can be part of the governance process for complex and high-dollar projects, but even smaller projects should have at least one as part of the overall design and requirements review.

A good Phase 1 stage-gate design allocates just enough budget to accomplish the following:

  • Discover and document all functional and non-functional requirements
  • Create and document a design that meets all requirements, or identifies gaps
  • Identifies all hardware, software, resources, and third-party vendors that will be needed to complete the project
  • Compares the design and all known costs to the original budget and business case

Only after completing these steps can an informed go/no-go decision be made based on validating the original project and budget assumptions. The output of the Phase 1 stage-gate can be used to develop requests-for-quotes (RFQs) for smaller projects, and request-for-proposals (RFPs) for larger initiatives. Larger projects may also justify several phase-gates after the following steps:



  • Create a paid Phase 1 initiative for a vendor to conduct a wireless site survey to determine the equipment needed for coverage, and then send the design document out to several providers for proposals. If you are paying for the wireless survey and design, there should be no expectation that you are going to use the same vendor for the complete project, although it is certainly an option.
  • Use an experienced independent contractor to discover and document requirements for a new software package, such as financial reporting. Take those requirements and turn them into an RFQ , or RFP, and send it out to 2-3 potential candidates. Conduct your Phase1 go/no-go based on the completed proposals and select the winner. The caution for these types of projects is to not use a company to build the RFP that also sells one of the proposed solutions since the proposal might be biased in that direction. Independent contractors are sometimes better in this instance.
  • Use a cybersecurity assessment to build a security program roadmap, prioritizing certain investments over 6 month or annual periods.
  • Utilize a Phase 1 assessment to develop requirements that can be used to determine the best fit for a managed service provider.
  • Utilize a Business Impact Assessment to feed into a disaster recovery initiative.
  • Create a Phase I project to assess the capabilities of your data center and use that to drive additional projects to increase maturity

The power of Phase I comes from its ability to utilize a small investment up front to identify and reduce risks before they become the cause of your next failed project. As you go through your next budgeting process, think in terms of multiple project phases and reduce risk, stress, and precious business capital.





Categories: IT Management

Tags: , , , , ,

3 replies

  1. Nice post, Mr. Weaver.

    Just curious where you see Agile practices fitting into this. I’ve found that discovery is an essential part of every project that requires the development of proprietary software (even if you use a vended service as part of it), and business needs to be prepared to react when something new is discovered.

    Despite the traditional approach of waterfall assessments, it’s more the exception than the rule that nothing is forgotten or things do not change in the course of a project. Unless I’m really misunderstanding, I would say in Phase I, “Discover and document MOST CRITICAL requirements” is less inclined to allow the discovery phase to spin too long. Even this phase has a cost to it. But creating a minimal viable product, at least in what I’ve produced, has been enough to move things forward.

    I’d say another huge reason why IT projects fail may even have less to do with up front planning, but the inability to effectively communicate. This responsibility doesn’t fall entirely on IT. But expectations, without adjustment over time as they become unreasonable within the scope and challenges a project faces causes way more damage than just a killed project. It usually creates person strife. It creates reputation of unreliability. And it can make it way more difficult to recover to move forward with the next successful project.

    Again, great post. Look forward to reading more.


    • Thanks for the response, Dan. All good points. Agile sounds good and it works in software projects when you are paying for capacity, such as how many stories can you complete in x amount of time. It is a little more difficult in infrastructure projects even though I have tried. I think even in software projects, delivering that first minimum viable project could be a Phase I. Then the client or company can decide on future sprints and capabilities. To your second point, the most important thing I have learned, some recently, is to make sure there is a business commitment and a business leader who is taking responsibility for the outcome. IT lead projects seldom work –
      even though IT Leaders may be passionate about it and know it will make the company better. I have also learned the importance of project governance. If the business commitment diminishes, or the scope increases, it is time to reassess the value of continuing the project or allocate more resources. IT Leaders take on way too much pressure to deliver when the business needs to be along for the ride to take credit for the outcomes and share in the responsibilities. Someone in the business needs to care about getting it delivered more than I do and they need to be pulling everyone else across the goal line and not serving as a gatekeeper or roadblock.


      • Thank you for taking the time to reply.

        I totally agree with what you say about “being along for the ride”. There are a lot of business-side participants out there that like to treat IT less like an opportunity to meaningfully collaborate, and more like a “consumer-product” relationship: “What? You can’t deliver a cloud-like infrastructure or a replacement for Excel on a fraction of the budget MS/Amazon/Google have for this kind of thing? I want my money back!” 🙂

        I know some IT leaders fear that getting business side too involved can lead to micro-management. And that is definitely a danger. But if healthy boundaries are set, it also sets expectations and offsets some of the load you’re talking about. People tend to care about what they’re held accountable for. If business can pass the blame solely to IT, they almost always will.

        Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: