Deliver
As the process is called Model Driven Delivery, then it makes sense to think about the deliverables first, before we think about anything to do with modelling.
Understanding the value that EA needs to deliver
The deliverables which your stakeholders are expecting to see will clearly differ massively between projects.
But in our experience, these seem to split roughly into three different types:
- Project-specific, which split further into:
- Deliverables which are for the internal use of the project team, for example, designs to be passed on to your developers
- Deliverables which are for external use, for example requirements documents to go back to stakeholders, or design documents intended for an external development team
- Cross-project deliverables, for example, a company-wide enterprise architecture.
Each of these deliverables is constrained in different ways:
- For the project-specific, internal deliverables we have some flexibility over how we deliver what’s needed – it’s our project.
- For the project-specific, external deliverables, we may be more constrained: certain stakeholders may demand their deliverables in specific formats, like a Word document or an Excel spreadsheet, which we might not be able to change.
- For cross-project deliverables, we may also have some flexibility over how we deliver. For example, if we are producing a company-wide Enterprise Architecture, we might be able to choose whether it’s delivered via a web site, a document, or a presentation.
But only when we understand
- what these deliverables are,
- what they need to contain, and
- who will consume them
..can we really make a start on Model Driven Delivery – otherwise, we don’t know where we’re driving towards.
You’d be amazed how many teams of modellers start out modelling, and only much later think about what the deliverables need to be, and how they will be produced. Understanding what those deliverables will be can itself be captured in a model. So if we need to deliver some User Stories, remember which stakeholders who are product managers for them, and link them both to our business goals, then these are some of the ‘things’ which our model must contain. This is the start of a ‘meta-model’ – which just means it’s a statement of what will be in the model.
People
This is a chance to engage with the consumers of our modelling work, and find out what they really need – as opposed to just giving them what they usually get.
One of my formative experiences as a new Business Analyst was having an experienced tester allocated to the team, to help us write more useful Use Cases. I thought I was an expert Use Case writer, but when the tester saw what I was producing, he quickly showed me where I needed more – and sometimes less – detail, so that his testers could do their own jobs better.
There is a lesson here for all of us. The initial conversations I had with the tester were not comfortable. He challenged lots of things I thought I knew about writing use cases, and that didn’t make me happy. But I gradually got to see that he was the person who should decide what my deliverables should look like, not me, the ‘expert’.
The Forgotten Stakeholder
We’ve noticed that one key factor which separates really successful use of models, from ‘just ok’ implementations, is whether Project Managers are included in the list of stakeholders. We often focus on the ‘headline’ project deliverables – designs, documents etc – and forget that the knowledge in a model can really help the day-to-day activities of a project manager. Just adding some numbers, some more traceability and a little thought can make a model a good source of project knowledge for a PM. So add them to your list.
Benefits and outcomes
So once you have identified the people who will use your deliverables, get to know them, and find out what they really need.
- Chances are it will NOT be a 500-page document which describes every diagram you ever created for the project. They might prefer a simple spreadsheet (“all my great modelling work wasted!”), or a document with just the stuff they care about, or a web site they can refer to. Or they may need your modelling efforts delivered into their toolset, not just dumped out of yours.
- If the deliverable is a document, then don’t be content with ‘my deliverable is a document’. Dig deeper. What should it contain – not just lists of things, but maybe also diagrams which show how the ‘things’ in the document are related?
Activities
The activities for the ‘deliver’ phase are therefore split into two bits (actually, there will be three, but more of that later).
- Activities which happen at the start of the project, where we find out who wants what
- Activities that happen later, when we actually produce those deliverables.
Initial Activities
- Discover the consumers of your deliverables. Using the well-known ‘V’ model of software projects can help here. This suggests that you should explore the needs of six sets of consumers:
- Those who follow you in the project life-cycle
- Those who are opposite you
- Those who preceded you
- Those who will peer-review your work.
- Your project managers!
- Future you. When you come back in 3 years to try and re-use the knowledge you’ve created, will you understand it ?
- Find out what those consumers need, and capture both the content and style of their deliverables.
- The way in which the deliverables get delivered. Try to be a bit smart here. Your consumer might SAY they want a document – because that’s what they have always been given, but give them a choice.
- Maybe a set of spreadsheets?
- Or access to the model itself? When the only option was to dive stright into EA this could be a problem, because the model contains loads of stuff a consumer doesn’t care about. But now with Prolaborate you can create customeised views and dashboards that can display just the relevant outputs.
- Capture the individual deliverable requirements in a “meta-model” – a simple diagram. Define the different ‘things’ you discover, with examples of what the consumer thinks they look like. So don’t just say ‘requirement’ is a thing – capture what the consumers think they should know about each Requirement.
- Work out – at the start – how you will produce those deliverables from your model. DON’T wait until there is a panic at the end of the project to do this. We STRONGLY suggest using some kind of automation to create the final deliverables, where the deliverable doesn’t need any editing before it gets delivered. Plan to keep the model as a ‘single version of the truth’
- Maintain this information throughout the project. It may change, and it will certainly be useful to future projects, so be prepared to evolve how you do things – in a controlled and managed way.
End Activities
If you followed the steps above, and the detail which follows, then this is the easiest part of Model Driven Delivery: just publish what’s needed. You’ve already got the right stuff in your model, you’ve engaged with the right people, and have a high-quality model full of relevant information. So just press the button and relax.
Well, not quite.
The ‘Deliver’ activity can be a lot like ‘Engage’ – you’ll get feedback, which will mean you have to make changes.