The term 'Inception Phase' is often used to signify a project's beginning. Isn’t it really the birth? There are many similarities between a project's lifecycle and this familial analogy.
Inception happens much earlier with a glass of wine, maybe two. That first thought, “Hey, wouldn’t it be neat if we had a…” Complete the sentence to fit the situation. It is at this point that the ball gets rolling, so to speak, and someone decides to invest some time to explore the possibility of making something happen. The originator courts the business manager, selling the concept of the idea, until there is approval to move forward. Voilà! It is conceived. Someone commits to carry and nurture the project, allowing it to incubate and mature into a viable form that can properly benefit the organization as a final product. After the proper gestation, the project is born and has a team assigned. This is the transition that many methodologies errantly label inception.
Many companies have some form of a portfolio management group to manage their projects and their backlog. The projects they govern range from network pulls to new software development. However, most use only one methodology to run these projects. It may be waterfall, Agile, Critical Chain or some other process. This is analogous to having only one knife in the kitchen. Anyone that has cooked more than a few meals realizes that a table knife is insufficient for all your kitchen needs. It purees tomatoes, cuts meat poorly, fails at filleting fish and suffers as a steak knife. There are hundreds of knives, each designed to do some specific job. As with many jobs, some tools are better than others are for certain tasks.
"Technology... is a queer thing. It brings you great gifts with one hand, and it stabs you in the back with the other." This quote, delivered by C. P. Snow, is one we should all live by. Mr. Snow was a physicist, a novelist and a bit of philosopher. Technology brings about great benefits that many of our projects rely upon. We are using it right now. However, take pause to reflect on how technology is also our nemesis. It haunts our projects with its false promises and lures us into implementing superfluous functionality.
Yes, I am on that soapbox. Ensuring that maintainability and adaptability are part of a system is a "best practice," extensibility is not. To the extent that a highly structured system is extensible, that is the end of any commitment to building for the future.
Adding hooks and stubs for something that may not happen, confuses and clutters the design of the resulting system. Building and running prototypes wastes time. Making a system extensible adds significant undefined scope. The reason is that no one knows what the future will bring. Furthermore, how can it be tested if the systems it is interfacing with are not defined?
The other day a friend said that there were three reasons for project failure. I took exception and stated there were two. As I thought about it more, there is only one. People are at the root of all failures, everything else is a symptom. Let’s look at some common reasons.
The project is over constrained. People set the constraints. If they do not understand the project well enough to set the constraints, or listen to the people that are suggesting the constraints, then they are the problem.