There are many tried and tested implementation methodologies and countless variations on a theme. Common practice is picking and choosing the bits that work best for a given target environment. Hybrid, agile, waterfall, call it what you will. The bottom line is we learn from every implementation and hopefully adapt. Or do we?
Last century expectations on delivery were well matured and mostly agreed with business stakeholders. Not saying they were successful or optimal, but well known and acknowledge. The process that were required to deliver were mostly understood together with the expectation, speed to deploy, timeline and project management process.
Generally the sense of rapid and/or dare I say “agility” was firmly grounded or caged within the waterfall process that drove delivery in the main back then. You know how it went; Requirements definition, functional design, build, test, launch etc . . . . so last century!
Cloud computing comes along. Software as a Service explodes. The sales proposition drive speeds and agility of deployment as a key value prop and RoI. Remember Salesforce.com “Click not Code”! The rush to cultivate a successful implementation methodology to support this new paradigm and business expectation continues to march on. But that said practices of yesteryear are definitely off the menu this century.
Now the nature of Software as a Service (SaaS) demands a healthy and growing relationship with the end user to maintain renewing subscription. Agile sends us all into short termism on the backbone of a lack of core foundation.
This is the very foundation of the business model. Execution of a SaaS project should start with that relationship fully in mind. Basing a project upon ridged and constrained scope and deliverable is a conflicting and contradictory engagement model for SaaS (see my earlier post, a subject dear to my heart Statement of Outcome). The need for a SaaS Rapid implementation methodology is vital.
So where is this going? In my experience running a Requirement Definition and Design stage is now so tightly coupled that defining requirements as a blue-sky, white-sheet, blank piece of paper process and is extremely dangerous to the delivery of a SaaS solution.
Take the core principles of multi-tenancy SaaS and take any SaaS solutions; “the constraint is in the SaaS solution delivery model and business complexity challenges whilst working within this which, pushes projects back into classic development mode?”
A SaaS solution needs a methodology that embraces it delivery model, speaks clearly to rapid implementation and defines business requirements within it core product capability as a win/win to renewals.
In addition, the SaaS product model must exhibit sufficient functionality for complex business requirements for its space. The SaaS Implementation Methodology therefore must speak to a requirements definition that aligns directly with the design of the SaaS product.
Merge the Requirements Definition and the Solution Design stage to address the SaaS delivery expectation model as a SaaS Rapid Methodology and align product capability road-map to the level of customisation based on the implementation feedback at the front line. The subscription economy demands it in the SaaS application space.
A LIFE LESS ORDINARY 