The Inefficiency of Circling Back

What is the Planning and Discovery Phase of a project?

The Planning and Discovery Phase is when structural and organizational components necessary to guide the project are developed. According to Manion, “Planning entails nailing down scope, stakeholders, and measurable objectives, and identifying who and what will be impacted by the project.” You then build plans for how you will manage and control the project, such as communication and change control plans. Manion says, “Discovery includes gathering and analyzing information about the business domain, business processes, and existing systems for use as building blocks for requirements and design specifications.”

Why is this phase so important?

This phase might seem like a lot of extra work, time, and money—especially when you already have an idea of what you want—but skipping it risks even greater costs. Manion says, “When technology projects are undertaken without first developing a strong foundation by completing those critical preliminary tasks, the projects invariably end up in an infinite loop of identifying a foundational need and dealing with it on the fly, circling back again and again on various tasks to gather basic structural and organizational information, usually at the most inopportune times.”

Do all projects need this phase?

This phase isn’t just for large-scale software implementations or custom application development projects. “This phase is required for all IT projects, and especially those that are going to engage a vendor. It is the basis for determining where you are, where you want to go, and how to best get there,” Manion says.

It is needed no matter what development methodology is used—agile, waterfall, or blended—no matter the timeframe or budget. But Manion emphasizes this phase should be scaled accordingly for the project. Overbuilding project controls can be as damaging as underbuilding, and you run the risk of team members finding project processes so onerous they don’t follow them. No “process for the sake of process” here. Some rigor, if it is adopted, is better than a lot of rigor that is not followed.

So if you have existing documentation, don’t start from scratch gathering requirements. Begin with a review and validation of the existing documentation. If you have a tight timeline or budget, consider prioritizing requirements into “must-haves” and “nice-to-haves” during this phase, or consider using an agile methodology that builds in opportunities to accommodate changing priorities.

What if I don’t have the budget to add a formal Planning and Discovery Phase?

If you still need convincing this phase is worth some dedicated budget, remember reworking the budget to add this phase can actually keep costs down. Manion emphasizes, “There is a lot of research illustrating how the cost of adding a single requirement is exponentially increased as the project progresses from planning to design, development, and implementation. If you get into development and realize you missed requirements, the impact to cost, time, and users is significant.” The graphic shown below, attributed to the IBM Systems Science Institute, depicts the escalation of costs to fix errors as the software development lifecycle progresses.

What can be done if I didn’t do this phase and have already started development?

If you’re reading this and you are in the middle of an IT project and skipped this phase, you can still step back and take time to validate and elaborate your requirements now. “If you haven’t gone live, it’s not too late. Even if you have gone live, it’s not too late. You can change things, but cost is going to go up.” According to Manion, it’s all about managing the “triple constraint: cost, quality, and schedule, and there are always tradeoffs. It’s best to go back and revisit the plans and requirements as soon as possible, and then regroup. Take the time to assess where you’re at and then do a gap analysis against where you need to be.”

If the reason for missed requirements and increased scope is not clear, Manion suggests doing “a root-cause analysis or Ishikawa diagram.” She says, “If you don’t do this, you may have a solution looking for a problem, as they say, rather than getting to the real cause and identifying the right solution.” This analysis will help you pinpoint why you are where you’re at. “If you put aside a couple of weeks for figuring out the problem, the solution will become evident. It is reported that Albert Einstein once said that if he had 60 minutes to save the world from some disaster, he would spend 55 of those minutes defining the problem. You can discover so much if you just take the time. Once you know what the problems are, prioritize what holes you should fill first, and get to work.”

What are things you wish clients knew?

“In general, what I would really like to tell all clients is you don’t have a software project. You have a business project that has a software component. Sometimes IT groups dictate to the business what they are going to get and don’t let the business share what they need.” Manion points out, “There wouldn’t be a project without the business need. This is not to say that the IT shop is not a critical partner in a project— they are—but IT should not drive the project, and should always remember they are supporting a business need.”

In Conclusion

At Resource Data, we understand that each client and project comes with unique requirements. It’s important to recognize that the chosen path for software development doesn’t solely determine the quality of the end product. Instead, it’s the implementer’s understanding of the business process, initiatives, and goals being supported—along with the resulting design—that defines its value.

That’s why we consider the Planning and Discovery phase to be a crucial element of every project. Whether it stands as an individual phase or has its deliverables integrated into the initial steps of the project, it sets the stage for success. It’s like the opening chapter of a great story, where we carefully listen, analyze, and plan to ensure we’re on the right track to deliver a solution that meets your unique needs.