An Evolutionary Kind of Project Lifecycle

This whole journey of looking into the creation of a system, examining and comparing it to the most effective system known brings us to the point where we know we have to consider at least two more factors. Research and documentation have been identified as being important. This has brought us to the point of now considering the whole process to akin to a project lifecycle. However, considering the point where we started we can still bring in the point of evolution to the idea of having a lifecycle and ensuring that it follows this original process.

A project lifecycle tends to be a single focused set of many processes connected up relying on dependencies and magnitude to achieve a single or small set of goals. The project lifecycle may in fact include innumerable different tasks or processes within it but the final outcome is generally well defined, even though amusingly in reality all these definitions may have been changed from what they were first planned to be. It is a fact of life that the larger the project lifecycle is, the larger the change and slippage that occurs within it. Though I have seen and sadly been responsible for complete changes to original budgets, timescales and resource costs that have completely thrown a project plan out of the window, some of my less proud moments occur in there somewhere, but … hey … experience always comes at a price.

Whether this will be called a project lifecycle or not as we go on there is a fundamental difference and to achieve it lets use a software paradigm of class. Let’s think of a project lifecycle in evolutionary terms. The success or failure of a lifecycle, or any part of it (and that is important) depends upon its ability to achieve its goal(s). Not only does the set of tasks and processes change that lies within it but also the structure and type of project lifecycle. The lifecycle itself must also go through a form of evolution, taking on any shape or structure that works most efficiently with the type of goal within it. So it is important that a project lifecycle be developed that checks itself and goes through a cycle of test and review – somewhat like a sense of self-examination.

Now this now sounds like it is entering new ground, so I hope someone more knowledgeable than I can guide or point to existing project lifecycles that can change their own structures to meet the demands of it. In a sense if it was a quality assurance program, then think of this extra function as the process of change management.

This whole line of thinking now is turning into an interesting challenge.

Be Sociable, Share!