Agile

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.

Doing the “right thing” by mixing your drinks or how not to wet your self

Posted on Updated on

DTRTIt was always going to be a challenging project. The end users had the attention span of a gnat.  The delivery was to change their way of working significantly.  We knew we were looking at an uphill battle of acceptance, agreement and adoption. But it was a transformational project and had benefits beyond the front line use (CRM).

My key sponsor knew how to play this landscape and knew how to navigate the culture and habitat of the business. As such he drove an extremely hard line on the project team and maintained a level of focus and engagement that ensured that we did the “right things”, not always “did things right”.

As the project manager this approach often conflicted with the fundamental way minds work in an engineering project discipline.  It clearly did not sit well with the project team. “Where is the best practice?” rang in each team meeting, “this doesn’t work with the deliver dependencies in the plan!”  Somehow we needed to find common ground and understanding with the business and agreed demarcation of decision making and domain respect.

I was accountable for the delivery of the solution.  It had to meet the business needs but also needed to be sustainable and workable across the wider solutions and process platforms.  It also must protect the long term ROI by the manner in which we engineered the solutions for several international areas of the business.

Some environments can tolerated the “do the right thing” v’s “doing things right” approach and other will push back. The birth of Agile PM as an example has been bastardised from it pure efficiency gains into a delivery expectation paradigm which is wrong, wrong, wrong.  It places business, projects and outcomes at risk by setting expectation that do not align to a design and puts avoidable pressure on all sides of the project. Some things we build need foundations; it isn’t just painting and decorating!

However, in this instance my sponsor had the positioning bang on and influenced the way I priorities and multitasked the project into what would “curry” favour with key stakeholders, answers their concerns and keep the project from by flushed down the loo!  The key was to make an early deliverable to the end user communities and make an immediate and important win whilst building solid reputation and greater tolerance of the project for doing thing right going forward.

I must confess, at the beginning of this journey this approach created some degree of challenge for me and great anxiety for the team.  It went against all my experience and best practice as a PM. I was tasked with managing a delivery whilst my sponsor was tasked with delivering an outcome. I have since come to realise that these in essence are one and the same.

So over too many drinks one night this miss-alignment resulted in a heated debate (constructive and open) between us. My Beersponsor resolved it by setting me a test.  This proved his point and influenced how I would assess delivery forevermore.

“You have been out all night drinking copious amounts of beer. You’re hungry and in desperate need of a toilet. You grab a microwave curry on the way back to your flat. Keys in the door into the hallway and you see that you have some messages on your answerphone (those were the days). So you’re hungry, desperate for the toilet and there are messages waiting for you. What do you do first?”

I’ll leave you to work out what is the correct answer and please let me know by leaving your comment below,

Suffice to say this approach has continued to influence my thoughts and approach in engagements and project management. Where there is a clear need for “quick wins”  that conflicts with “best practice” it is important to find a way forward that allows leveraging greater stakeholder tolerance of the wider delivery and a more pragmatic direct focus on doing the “right things” by the team in order to do things right.

As a leader of the project team my task is to gain buy-in from all parties to identifying why a “doing the right thing” by your business stakeholders is the first deliver that any project needs to make.