Does this sound familiar? You’re in the middle of designing—or worse, developing or implementing—your system, and you discover a missed requirement or a new stakeholder. Now you have to circle back to validate and elaborate the requirement or bring the (probably annoyed) stakeholder up to speed and discover their needs. It is likely you will have to revise your design or plan to add a feature in a later iteration. Either way, you’ve lost time and money.
Continually having to circle back to revisit scope and requirements is preventable through up-front planning in what’s commonly called the Planning and Discovery Phase of a project.
We spoke to Pam Manion, a Resource Data Sr. Project Manager/Sr. Analyst with more than 20 years of IT project management and business analysis experience, to learn more about this phase and why it’s so critical to the success of software projects.
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.”
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.”
“This sets the project up for a vicious cycle of crisis management: moving from fire drill to fire drill, making intermittent progress, but paying the cost in terms of burnout, delayed schedules, increased budgets, decreased scope, and unacceptable deliverables. All the while, stakeholders are demanding more: more meetings, more status reports, and more accountability.” Our heads spin just thinking about it.
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.
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.
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.”
“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.”
At Resource Data, we recognize that every client and project has unique needs. Regardless of the software development path selected, the final product is only as good as the implementer's understanding of the supported business process, and the resulting design. We therefore consider the Planning and Discovery phase key to every project, whether as its own phase or with its deliverables incorporated in the initial project steps. If you found this information useful and would like to discuss how Resource Data can assist with your IT projects and needs, contact us today.