Introducing the known requirements to the feasibility team:
If you’re working on an agile project, one with volatile requirements or a tight deadline, you won’t have deep requirements when you begin the Feasibility phase. A request or idea has been approved for a feasibility investigation, and no one has documented detailed requirements to this point. Your idea is relatively new, and you’re working rapidly to either start the project or dismiss it. The information that is available is presented to the feasibility team. The idea usually has a champion or author who can meet with the team and go over the concept. This person brings in all the information they have at this point, whether it’s a diagram on a cocktail napkin, a detailed flowchart, or a mini functional specification. The following items can be analyzed during the Feasibility phase:
- User scenarios
- Storyboards
- User stories
- Marketing proposals
- Use cases
- Competitive analysis
- Rough sketches of process flow
- Financial analysis
- A website where a competitor is already using the idea
- Mock-ups
If your idea comes from within, you may have a white paper created by someone to outline the idea.
What does a feasibility investigation look like?
When you present your idea to the feasibility team, they will provide initial feedback and subsequent commentary after performing their offline feasibility work. The initial review can provide positive feedback or identify issues immediately. You should inform the feasibility team that candid conversation is not only desired but critical to the process—you don’t want to go forward with more extensive feasibility analysis if you don’t think the idea is viable. You should also prepare the idea owner for candid feedback.
Encourage the owner to demonstrate their passion for the idea, but at the same time prepare them for frank conversation and a thorough review of the proposal. The time you spend on feasibility analysis will depend on various factors such as the idea’s complexity, the availability of the feasibility team, and dependency on third parties to provide information. An average feasibility analysis begins with a 1- or 2- hour meeting that kicks off the process; at this meeting, one person discusses the known requirements with the feasibility team. The feasibility team reviews the idea with the presenter, and team members ask questions about the customer, the project’s value, and potential technology needs. This first meeting may provide enough information to make the go/no go decision, but usually, a few questions remain that require team members to work offline to get the answers. This offline work may include the following:
- Looking at existing code to see how it can support the request
- Consulting with a vendor about a possible solution for the request
- Doing deeper statistical analysis
- Reviewing competitor functionality to see if they’ve addressed the same idea
Typically, the team regroups after 2 or 3 days to review their offline work. At this point, they usually have enough information to make the call about whether to continue to develop the Project Business Case.
