Analytics is the particular branch of IT that I exist in. Here, change is the norm and technologies are rapidly evolving.
This means that a project may well start in a particular shape, and end up in a completely different one. And this may be perfectly acceptable to your client, which is an interesting paradox if you compare analytics projects to, say, a home improvement project. If I am having my kitchen changed, I’d quite like it to be a kitchen at the end of the project. But that is not necessarily the case with an analytics project.
Why is this ? Well, to continue with the kitchen analysis, we’ve been cooking food for almost as long as we have existed as a species. Analytics, on the other hand, is for ever new with knowledge, skills and outcomes that have to be discovered and implemented.
I have noticed, over the course of many – many – such projects, that the implemented vision is frequently different from the planned one. This is because, through the pretty amazing tools provided by my esteemed employers, new things about the enterprise are learned during the data discovery process, and business priorities may change over time. It then becomes important to seize opportunities and adjust the business case, and thus the outcome.
This difference between the vision that underpins a project at the start, and the end result is what I call the Reality Gradient. It is a key concept from a consulting point of view, and it can be expressed as a measure. As an analytics consultant, you will need to be the lead or a key participant to steer the project and the client through uncharted waters. Defining this gradient as a measure can simply be a ratio of initial expectations matched against project outcomes. The fewer the matches, the steeper the gradient.
As with all measures, few are significant on their own. In this case, you also need to have a measure describing project success. This is more qualitative, in that it matches benefit expectations at the start (the business case) with benefit outcomes (if any).
Now that you have two measures, you have means of learning quite a bit about the people, the enterprise and the methods employed during the course of the project. Put simply, a high-gradient, high success project indicates agility and opportunity, while a low-gradient, high success outcome validates estimating, project leadership and indicates pre-existing knowledge (or immense luck).
If we accept that a Reality Gradient is inevitable, then we need to make sure that the journey is survivable. It is another paradox of agile methods that these are supported by very basic skills, even if these are applied in new ways. It’s worth doing a brief excursion into one of these core skills: Project management.
It is my experience that, across the many technologies and methodologies I have encountered, a key factor with low outcome projects has been a project management deficit. This can take two forms: Quantitative – there is not enough project management – and qualitative, where there is project management but it is not the right kind.
This can be a difficult issue for a consultant. Project success is an important career element and being affected by project management shortfalls is simply not welcome.
My advice to consultants is to learn about the key fundamentals of project management, and assess where these fundamentals are lacking on projects. These fundamentals are:
- Business case
- Communications
- Planning
- Status recording and reporting
- Risks, Assumptions, Issues and Dependencies (RAID)
Each of these points deserve more description. But knowing that these either exist or not, and are fit for purpose, is in my view a vital project survival strategy.
Consulting organisations will have different ways of supplying these skills to colleagues.
Of all the points described above, the least important is planning. I can feel the sharp intake of breath, but you can plan a failure if you neglect any – any – of the other points.
Plans are key for estimating and mobilising and should be as detailed as possible. Once the project has kicked off, however, you should work to the project milestones, but you should simply record what is happening rather than spending ages keeping the plan consistent. I’ve found it acceptable to review and adjust the high-level plan at relevant intervals, providing I have a good record of events and decisions made (see status reporting).
There is a valid reason for this, and I am pleased to loop back to my Reality Gradient. It is that the analytics projects you will work on will yield new data, new ways of addressing business cases, requiring a change of course. Unless you have the luxury of a project administrator, you will not be able to revise the plan in detail every time an opportunity presents itself.
And in any case, unless this is your engagement role, you are a consultant and not a project manager. But you will be impacted if the fundamentals are not adequate.
Briefly about status reporting: It is is essential for all consultants on projects to have basic skills in this respect. Progress on tasks, issues, risks should be captured and aggregated in a regular report which will then track progress against milestones and objectives, and document changes in scope. It is also essential that this status report be reviewed with the client on a regular basis.
Communications are self-evident: regular standup meetings, clear communication lines, defined escalation process, good status reporting are all aspects that should be examined.
The Business Case may change over time. When it does, the project must follow. Meeting business case expectations is of strategic importance as it may well be gateway to further projects and benefits. Understanding this, and knowing when and why it changes, means that delivery is focused on the current goals.
And then, there’s RAID. It’s worth spending time evaluating risks, as a few of these have a chance of turning into issues. Communicating these risks to the client is key, as you can work cooperatively to mitigate the risk and resolve the resulting issue. Assumptions are rather harder to list, as being assumptions, you are tempted to take things for granted. Here, experience is key as you will remember assumptions that bit you hard in previous projects. Issues, we all know about – tracking them and resolving them is a necessary, if burdensome task. Dependencies, again, rely on experience. Frankly, I won’t go on too much about this, there’s plenty to read and learn in books and online.
All these are fine project management disciplines. Not rocket science, but the key there is in the word discipline – these items must be present in any project, if not by you, the consultant, then by someone else in the team.
But above all, you must be able to understand, manage and communicate the Reality Gradient. To do this requires transparency and trust, and quality interactions with your customer, with regular evaluations of the direction a project is taking. You’d neglect this at your peril.
A Blog about Data 