Successful project management starts with a solid, stable foundation. The foundation of project management is the “Initiation” phase. One of the blocks in that foundation is the “feasibility study“.
Simply put, the goal of the feasibility study is to answer the question, “Should we undertake the project?” By conducting a feasibility study, you’re trying to minimize risk. Among the issues that determine a project’s feasibility are:
- What are the goals and objectives of the project?
- Is there more than one way of arriving at the desired result?
- Does the project fit with the company’s overall philosophy and long-term strategy?
- Will the project meet the goals and objectives of all stakeholders?
- What are the the project’s costs and benefits?
- Does the company have, or can it readily obtain, the resources it will need?
- How long will it take to see results?
- Will the project result in a product that generates positive cash flow?
- Does the project (i.e., the product) have long-term potential?
- Are the risks known, understood, and manageable? If the risks are not manageable, are they acceptable?
As you see, there are an awful lot of questions the feasibility study has to answer, and each of these questions deserves a post of its own. Of course, as many questions as you could ask — the questions above will naturally lead you to still more questions, potentially ad infinitum — your feasibility study must be finite.
You can’t possibly capture every bit of information on a given subject — there is no such thing as perfect information (ask Wall Street). If you keep insisting that you need more information, you run the risk of paralysis by analysis.
At some point you have to say to yourself, “Knowing what we now know, do we proceed?” It’s not a perfect world — and yours isn’t a perfect company — though with the right preparation, you are bound to experience many more successes than mistakes.
It’s also important to keep in mind that customer input equals a successful product. So why do so many products make it to market without the customers’ point of view in mind (and fail miserably)?
A customer representative in the decision-making process is essential. Whether this is the project manager acting on behalf of the customer, or better, an actual customer, hearing and understanding that perspective adds important insight to your product definition.
This is not to say that the customer representative designs the product, but certainly a customer’s input needs to be inserted into the process as more than just an afterthought. As Scott Bellware writes in his post on customer service:
“As a product designer, you should already know what it is you’re building. You should have a strong vision for the product and already have a visceral sense of the customer’s expectations, needs, and desired customer experience.”
It’s not something that enters the project after the fact. You should have a “sense?”–or, more like a validation–of your customers’ needs and expectations as input in the definition and design phases. Customer representation validates what you’re doing and lets you know the product would actually appeal to your target customer. It’s more than creating a customer feedback outlet for a product that already exists.
How do you represent your customer in the development process? Does the project manager stand in? Do you solicit actual customers? How does it work for you?