A common language revisited

As an organisation grows, it gets more complex. Process and culture are inherently more complex than technology. A common approach is to use a fixed, prescribed solution to the complexity as this makes it easier for people to understand, however you understand the solution but not really the problem.

Complexity in process and organisations is not insurmountable and one approach discussed within Red Hat Consulting before is to use a common language or syntax when discuss projects so that different stakeholders, within Red Hat or the organisation that is being worked with. Removing ambiguity ensures that collectively there is a common understand of the problem. Over the last few years Red Hat Consulting has looked to use SEMAT Essence as the basis for dialog around projects. Whilst quite a bit of work was done in applying this to projects, its uptake was limited to a core group of practionners who continue to use it successful. The SEMAT style also influenced the Ready to Innovate tool (upstream, enterprise ), which has become one of the key tools for assessment and lead generation.

In it’s simplest form, SEMAT Essence uses a common set of criteria (known as Alpha’s) to define a project:
* Stakeholders
* Opportunity
* Requirements
* Way of Working
* Work
* Team
* Software System

Each of these Alpha’s exists in a series of states, starting with Not Set and progress through 6 or 7 states which describe the current situation or a project.

Using the alpha states it allows 3 things, in order of progression
1. understand, agree and demonstrate the current situation of a project
2. discuss and agree next steps to progress the project
3. build repeatable activities that move projects forward

As such it can be used as a framework and approach to understand a new project, qualify the level of relevance and interest to a consulting organisation like Red Hat. When consulting get involved its usually runs a discovery session, which will qualifying before it’s confirmed and run. Also, after it has happened, further qualification will see if there is a viable project going forward. In the early stages of a project like this, it is the Stakeholder, Opportunity and Requirements Alphas which have states set and only when a project is understand that Alphas like Software System come into play.

The diagram above describes a generic workflow for the initial part of a consulting project, with the relevant Alphas and their states and whilst they may not be correct (for some organisations) they show that a project can be understood in a standard way. One of the other benefits of this approach is that any project’s health can be assessed and that very different projects can be compared easily.

One of the benefits (and challenges) with SEMAT Essence is that is extensible and when you look to develop practises of repeatable activity it can get complex. Understanding that things you do (activities) are different from the things you work with (alphas) help. An activity such as a Discovery Session, should advance the state of one or more alphas (as shown above). By agreeing the state before the activity and agreeing on a end state means that the value of the activity can be easily understand.

I can recommend a read of the Essence Lite guide, as it covers much of the above and gets you started on you can easily use the approach on projects.

Spread the love

Leave a Reply

Your email address will not be published. Required fields are marked *