SaaS

Over Engineered – Cost of Bells, Don’t Need Whistles

Posted on

ClockWorkI have been busy exploring the varied and wonderful world of legacy solutions and modernisation compatibility.  My role has been listening, understanding and exploring business critical requirements and looking for solutions and scope from which to devise a way forward for transformation and improved efficient business practices. All at a cost! Are you willing to pay? Can you afford not to? Do you actual know what you want, what you need?

Now I really feel for the teams who after years of blood, sweat and tears and loyalty to an organisation have had to come to terms with seeing their “labour of love” criticised, or analysed as to what the future shouldn’t be like.  I hear statements like “we want to simplify”, “this is far too complex and can’t adapt”, “we over engineered this” . . . .

Having to make business wheels turn under business as usual pressures, the constant demand of changes and having to lovingly safeguarded  doing business using is a champions job and no small feat! However too often I am seeing this endeavour become a thankless task when modernisation comes into play.   I’ve been here!

We should thank these teams for the hours of devotion as it is their past innovation, solution engineering and practices that has helped a whole software consulting industry  learn what, why and the many “how” that helped develop new solutions, technologies and paradigms (Cloud/SaaS).

Decisions are made for the circumstance of the day.  Solutions built to support the needs of that era weren’t meant to last a life time and be infinitely flexible and accommodating.  At some point they will just not be able to cut the mustard any more. They will be no longer fit for purpose.  The world matched on . . .

Business moves on, commerce and industry devise new needs and opportunities, models and processes develop, opportunities demand new support models, and yet sometime the infrastructure that is built to support the legacy business model is forced under pressure to perform above and beyond in the new world model!

B-W-1I recall in another life where the development of the solution had to address the most bizarre requirements at the edge of every possible combination of circumstance and possibilities.  This is often termed “future proofing”.  Tell me who has the crystal ball and have really ever seen “that” coming”?

This leads to the classic costly over engineering and the long haul cost of ownership and maintenance change, fix and repair cycles, let alone integration, scaling and portability challenges.

I came across this coffee machine at a wonderful facilities provided by a very well established consultancy. It caught my attention in relation to this topic over engineering, bells and whistle and then the cost of ownership and maintenances. It got me thinking while waiting for my coffee.  Will it ever be able to make a good cup of tea? Was it ever meant to?

Too many moving part, accommodating people interaction experience verse their responsibility to (place the cup under the tap head), compensating for people effort and generally build complexity for more vulnerability and cost of ownership. How many times have you designed a solution around people capability over what would work simplest?

Kiss

Easier said than done when there is more than one engineer having fun!

Gee Businesses Make It Tough To Change – Change the Tune!

Posted on Updated on

avril-lavigne-1

The thing is everyone in the room is a solutions architect. But not one a pop star! There’s tension and their pain and emotional investment of a life time career is exposed and raw. There is great endeavours and knowledge experts that would score highly in Master Mind for their chosen subject, and a fascinating array of professional office politicking. But not one harmonious tune.

My role gives me great insight into many situations, sectors and cultures where change and design clash constantly and where ownership and authority dance to the tune of a different song to that which they think is playing. They need to change tune but more on that later.

I see this clash more and more as enterprises make that move from old platform to Cloud and the realisation that standardisation demands a new song that only a shared platform can sing.

In the room they are all looking for a solution; they are all trapped in a decision of the past and now embroiled in the challenge of change. What often astounds me are the players in the room, the leadership of risk taking and the real issue; “our business model is no longer fit for purpose and our operating practice broken!”

Large amounts of operational expense are maintained in maintaining the modus operandi. Large capital expense is questioned and fought for to establish “betterment” against the backdrop of legacy.  This is modern enterprise business in a world of unpredictable change and overpowering competition of new business models of “subscription”.

The intent of all in the room is to do the right thing. The opinion of what is “right” is the challenge of culture, belief, experience and legacy at odds with each other.

When I am sitting in the room and layer after layer of conversation, deviation and ultimate indecision fills the air with noise and awkward body language, indifference, and/or dogma I can’t help having the tune “Complicated” pop into my head. You’re singing the chorus now aren’t you?

Chill out, what you yellin’ for?, Lay back, it’s all been done before , And if you could only let it be, You will see . . . .

I want these companies to go back to the beginning and try to find the true reason why the company and its product became. What drove it to success? Where is the value? What is the differentiator? Cling on to these and then ask:

Why do you have to go and make things so complicated?
I see the way you’re acting like you’re somebody else
Gets me frustrated
You fall and you crawl and you break
And you take what you get and you turn it into honesty
You promised me I’m never gonna find you fake it
No no no

If you fancy a sing alone try this!

Must thank Avril Lavigne fo adding to my corporate change wisdom and therophy.

Requirements to Design or “just get me there soonest” – SaaS Rapid Implementation Methodology

Link Posted on

Classic WaterfallThere 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, aligned, adapted, 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.  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.

Sweet SpotNow the  nature of Software as a Service (SaaS) demands a healthy and growing relationship with the end user to maintain renewing subscription. 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 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.

Tag Line

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.

Statement of Outcome – road to repeat business and continued subscription

Posted on Updated on

Contracts“We’re a customer centric company” proclaims the well-heeled account executive to the soon to be client.  “It’s all about the customer. Without our customers our Cloud/SaaS Company is nothing.”

But how does that translate into a company culture?  And how does that get realised in the execution of service?  And how does that define the customer relationship?

The expansive and exhaustive clauses in the Master Service Agreements (MSA) and Statement of Work (SoW) used to level set engagements have been laboured over, positioned and postulated to the nth degree to protect “all” parties.

The ink is hardly dry when the next signing is due!  Change Orders, Change Control and the endless negotiation on definition of accountability the ruin of many a good customer relationship. The cost and effort in tracking scope and reporting effort adds to burning up precious resource, budget and time. Is there an alternative?

Today the SoW and MSA are the established rule. But how does this fit with the social collaborative, agile method that we all profess to embrace in this Cloud/SaaS day and age? Is this the “outcome” based generation of delivery professionals or are we still entrenched in the “push me pull me” relationship of the last century?

Businesses can execute projects on a strategically optimistic level and become painfully compromised by this. Due diligence can cripple innovation.  Hope and vision is an important human emotion that provides motivation, focus and leadership.  A clear steer is needed in often uncharted waters.  The SoW should be the wind in the ships (project) sails but often becomes a storm rather than a guiding wind as knowledge and learning unfolds.

Ask yourself this; “did the last SoW you delivered against really reflect the effort and journey that was originally set out in it?”, “was what was delivered anywhere close to what you discovered you actually needed?”.

Experience has shown that conflict of interests, and at times crises of principle, between the persona of a Partner and the execution of a Supplier can create the worse in customer relationship; waste, inefficiencies, missed opportunities and lost success, all trapped within the framework that is the Time and Materials (T&M) SoW of the last century.

I have experienced both sides of the customer and supplier relationship. I have felt the pains from both. The supplier that wants to act as a partner and finds the SoW culture aligns to acting as a supplier. And as the customer frustrated by the supplier who fails to grasp the bigger picture to step up to acting like a partner.

I am not saying that accountability, definition, financial management, penalty and control should be abandoned. I am saying that what SoW measures in this day and age are probably not fit for purpose and need to look at delivery and reward from a new set of metrics.

When I think back on being on the receiving side (the customer) I recall that success came from suppliers that worked jointly with me to overcome a challenge. This created the support relationship to bring an engagement to a mutually successful position – an outcome and a partnership.   In this position at times it was necessary to deliver bad news to stakeholders and align with the supplier. But this was in preservation of the bigger picture.  I commend those suppliers who went the extra mile finding the guts to invest in the relationship. You know who you are.

Those suppliers that took up a ridged and tightly formed scope approach chasing the margin suffered a cautious relationship with the stakeholder community. In fact most of the suppliers I worked with who took that approach are not in business today.  Whereas most that partnered and invested in joint risk and challenge are.

Outcomes

In a recent Cloud/SaaS engagement it became clear that the needs of the customer could not be met by the existing arrangement and agreement. Both sides had a learning curve of industry and product that was steeper than first thought. Significant business change challenges and clear knowledge gaps existed that exacerbated the situation. Product capability and readiness impacted the shaping of the solution. The Customer’s ability to provide need support and definition lacking.  It was clear that the duration between pre-sales, SOW agreement and actual project execution highlighted the rapid change of business in this day and age. Our SoW was out of date before we started the project!

This further encouraged my thinking that the SoW should focus on mutual recognition of risk, creativity of mitigation and contingency of clear measurable business outcomes; reduced cost through efficiencies, increased revenue through business intelligence, reputational outcome through tracking CSAT, retention of staff, retention of customers and business, bigger slice of the pie.

How about a collaborative transparent approach across all players in the project with joint investment/ownership and reward written into an agreed Statement of Outcome (SoO)?  We all have some form of performance management scheme in our job roles and are familiar with these so why not make projects based upon the same SMART (Specific, Measurable, Achievable, Realistic, Timely) measures. Anything but scope, time and budget. All of which we rarely are really in control of as time elapses, scope changes and budget diminishes and more importantly, Business Changes, before the end is in sight.

So when I find the conversation focuses on a SoW and the tightly bound scope and engagement framework I ask myself “are we looking at the customer as a lifelong engagements?” or do we see them as a “revenue target for a fixed event?”

I argue that in this Cloud/SaaS subscription economy the latter does not hold weight. We need to rethink the terms of the SoW and look to embrace shared outcome for the longevity of a subscription through outcome based engagements (SoO) when it come to the implementing the solution and long term strategic revenue flows in a SaaS model.