Introduction
The Smart Lifecycle obviously offers a wealth of means for your projects. Is it then finally the one Hammer that will smash all different nails into the wood we all desperately seek?
Obviously not. Let us define the characteristics to which we confront projects to determine if Smart is the appropriate lifecycle.
We will be touching on typologie of the initiative, the amount of legacy involved, the degree of "documentedness" of the requirements, the architectural restrictions and completeness of the vision.
#. Typologie of the initiative
Change programme or system development?
#. The amount of legacy involved
aanpassen bestaande legacy in iteraties?
#. The degree of "documentedness" of the requirements
"We have already documented the requirements, can you give us a price?". A request we meet often.
These situations are rather treatorous. Obviously, the customer organisation has spent a lot of effort, to come up with written requirements. Usually, to their pride!
Often however, the parts that are so eliquently documented represent the clear elements of the demand. The blind spots are undocumented. And, since 'paper is patient', the requirements lack the confrontation with actual software capabilities.
Another pitfall is that the documentors are usually ICT savvy writers, that have interpreted the requirements to the best of their comprehension.
Fact is however, that a user quickly shifts gears, when looking at a conceptual solution in actual software environment. And he does not fully understand the written text in relation to the actual software solution.
Our suggestion? Use all that valuable input in short iteration cycles with the user and the development team. The effort will then carry forward in quick creation of Smart solutions!
#. The architectural restrictions
#. Completeness of the vision.
Many initiatives are formed into a project. However it is not always ready for a Smart project. If many business decisions still have to be made, building software might be the wrong priority. It is wise to ensure the completeness of the vision, building a situation where all stakeholders know the basic functionality the Smart project should deliver. Yes, you can 'use' an ICT project to drive such choices, but you cannot build a new insurance-product (marketing, product development, legal, etc.) from software alone!
#. Organisational capabilities
Can your organisation cope with the demand on resources you need for a Smart project? get key people into the project to jointly define the desired functionality?
We bet you are tempted to say "no, not possible, we cannot go Smart".
Consider the alternatives. Creating thick documents with one team, re-inventing what has probably meant with another team, and again when building... It might just feel easier to spread a lot of effort across time and across teams, yet a very bad idea in vivid markets with changing customer demands.
On the other hand, many a company has chosen the route to outsourcing or even to go offshore. Is it possible to go "smart" in that situation or do you transfer the challenges to meet your needs to a third party? Obviously this pushed your organisation to other capabilities, in governance of the process and for example testing.
But, are you in need of a professionalisation boost for your projects? Need more agility in the solutions? Need to support your businesss organisation when getting the actual demand clear? You guessed it... Smart is your route to go!