Awhile ago I was asked this question as part of a coaching session “Can you think of a specific time you have been influenced to change your mind and how?”
It took awhile to think about my response and with my smartphone in hand and the world of social media and apps readily and persistently available I kept pressing myself to think of a Cloud/Social Media example. You see, so much is given to this great wonderful, and it is wonderful, new frontier of connections and influence that one automatically relates ones life to this. That, or I need to get a life! I have had some great experiences and influences through the widen reach of social media but these have often been from a one-way learning view point. I am sure this will change as the world and our working life becomes increasingly dependent on who we can reach and where we can cultivate influence and advice. But as it stands for me it was people engagement that influenced me most.
I put down my smartphone, logged out of the various social media sites and recalled the moment. In an attempt to introduce customer segmentation to an institutionalised trade organisation it was key to not only provide the facts (statics) but also embrace the emotional decision making process of the board that would sanction its adoption.
This board was made up of the very people who would be impacted by a segmented engagement with the institution – turkey voting for Christmas scenario. There were clear power pockets among this group with influence that extended beyond the institution and into trade bodies and key customers. This could impact the outcome I was looking to achieve. Having done my analytical homework, proven the 80/20 rule and showed how cross subsidisation was supporting the masses of under contributors as the driver for improved customer retention I was set to deliver what I felt could only be a fait accompli. After all the facts speak for themselves!
A senior member of the committee agreeing with the segmentation strategy took me to one side; “You need to get the board to own the decision and then you need to support their decision through your analysis to validate it. Without this you will be seen as challenging rather than supporting the organisation.” This was a good point and a key consideration in what was a political and emotional arena. It led to a change in tactic and a more refined stakeholder management approach. Perversely I segmented the stakeholders and looked at each through the lens of “Voice and Sphere of Influence Profile”. This shaped how I would approach each member of the board and how to gauge their position on the strategy
The advice given and my experience in taking heed influenced my approach. I worked more one-to-one with board members, especially those that were identified as carrying the weight to see the recommendation through or best placed to champion the strategy to the very community it would impact. It is people that make decisions on strategy not statistic and this experience changed how I approached such matters going forward.
It is also, we hope, people at the end of the posts, feeds and links. But it isn’t the same as a hand on your shoulder and a quiet, yet influential word in your ear.
The order of the day was a complex in an international institutionalised practice desperate to move into “best practice” methods of doing business. Now surely “best practice” can only be defined in context of the performance of the individual organisation. You’re only as good as your last . . . . .
They had worked hard, tirelessly to assimilate all the requirements and categories them, align them, group them and dissect them. Good job clearly a momentous effort.
The list was extensive, each statement hanging in the breeze like leafs on a branch, connected and bound by their precarious stems waiting to detach at any moment under the stress of the changing breeze of business. They twist and turn on the branch, and not easily translate to the canvas of colour and texture that defines . . . . . . .
It was going to take a big effort from the team to pull this into shape. The countless workshops and PowerPoints, papers and examples given, received, digested, regurgitated and pondered only added to the strength of the breeze blowing the leafs and stressing the branches. The task stared us in the face, the cutting wind of Requirements Definitions. Were we able to see the wood for the trees?
But what is a statement of requirements as the first stage of a project life cycle? If we stopped to ask what is it we are trying to achieve and what part of a process we looking to complete or why do we need to do this, we may rethink an approach and weighting of this stage. For sure the business will change during the life time of the project and therefore our requirements may become irrelevant or just plain different.
We want to ensure that sufficient understanding of the domain space has been transferred into a project artefact and that the project is able to articulate what the project must deliver and for what outcome or benefit; “The solution should allow . . . . to do this to achieve the following outcome.“
There are several tools to help describe definition such as flow charts, Unified Modelling Language (UML) Use Case, Swim Lanes, User Story, State Transition Diagram etc . . . . However, we want to be able to communicate to a non-technical, non-engineering audience, typically business Subject Mater Experts (SME) and key stakeholders. These participants often work from the repetitive, process driven lens or day-to-day operation. Not the engineering lens looking to dissect and rebuild. Making conceptual requirements difficult to relate to the now of the everyday operation.
Assume in existence is a strategy statement, a vision, a mission statement and all that good stuff, something to hang your hat and scarf on in the stiff breeze of requirements gathering. Assume there is visibility of a value proposition and quantifiable KPIs. I guess if you cannot substantiate these assumptions you should STOP now.
The project is being set up for failure without clarity on this. Speaking to my previous blog (SoO) these should be listed and counter signed as part of the outcome partnering proposition between organisations.
For the purpose of this blog post let’s assume all that good stuff is in place. Otherwise I should stop writing now.
A requirements definition could then reflect the following:
- A reference number – Always useful and unique
- A short title – Representing the gist of the need
- A fuller description – Of the “What” – not how and should be singular in nature, one statement for one need
- Business Alignment – The “Why” this is needed and how it fits into the business operation and/or practice
- Strategy Alignment – A short statement on how this support the business strategy
- KPI – How the requirements will be quantifiably measured against the business outcome as business value (take it that Strategy Alignment could be qualitative measure)
- Audit/Knowledge Custodians – Who, when, SME, version, date etc
Yes there is a ton of other stuff but let’s not boil the ocean here. It should not include design and implementation matter or commitment to user experience and/or solution design. We are after all trying to relate business needs to a set of deliverable to form the exercise of design, not design as a seed to requirements. Reminds me of the saying “a good invention waiting for a purpose.”
Language, texture and tone. We need acceptance, buy-in and most importantly agreement and alignment to take these to a formal approval sign off. So this document has to be non-technical and speak a business language and not an implementation and/or technical one. It must bind leafs blowing in the wind into a coherent sway of changing winds.
As such it must be a collaborative effort and individuals on both sides of the table must approach this with a view of making this work. It must speak a common language and it must engage and satisfy many masters.
A by product: This exercise is a great asset to any organisation as a by-product often establishes the missing corporate procedure manual that can go a long way in managing the overall alignment and effectiveness of the enterprise.
So the next time a requirements gathering phase is initiated it may be worth looking at your template, tool kit and definition of this task and asking: “What is it that we are trying to achieve through this effort?”