BDN Development Workings
This page is for working notes, examples and background information. It will save us emailing big documents between us.
First thoughts are:
What's the personal gain from doing this? Anything we publish at the end will be public domain and not proprietary to any of us. I'm presently employed by the NHS as well as my own company. I'm doing this in my spare time and I'm keen to keep it public so I don't risk anyone at the NHS claiming intellectual property rights over my work. That shouldn't stop us putting our names to it and claiming credit for doing it.
Do we want to create one consensus BDN style? Or should we create a set of guides / rules on what a good BDN should contain without saying what it will look like?
I prefer discipline to dogma – leave some scope for personal initiative.
A working definition, 'enterprise' – a catch-all term to cover the big picture of people doing stuff. Depending on the context, it means initiative, portfolio, programme, project and also body, organisation, business, partnership. I'd like to use it to save having to type 'portfolio / programme / project' in every other sentence.
What's it for?
The purpose(s) of using a BDN are:·
Plan on a page / MSP Blueprint – a diagram that describes the enterprise. A summary of Means, Ways and Ends
Project planning chart – like a PERT chart that shows project interconnected project activities, the BDN shows a detailed rational set of paths from solution to objectives
Solution design – the BDN is a tool for making rational choices of what's required and how it will be achieved.
Stakeholder involvement – the activity of creating a BDN attracts people to take part and motivates them to contribute to the enterprise
[See the Benefits-led Enterprise for more of this]
Where does it go wrong?
Wrong players build it, leaders don't take part
Lack of iteration – one shot and it's done
Cargo-cult, lack of understanding of the principles, copy someone else's diagram
Features, outcomes, benefits, objectives – overlap and / or poor definition
[See Bad BDNs for examples]
Boundaries – setting clear limits on what's in scope. Interdependent BDNs and our place on an infinite mat of overlapping BDNs.
CSFs – When to keep out the givens, e.g. trained workforce, competent leaders shouldn't have to be included in the project, should they?
Are we being too low-level by concentrating on benefits?
Ought this to be a Strategy Dependency Network? What's more important, objectives or benefits?
How to show the dependency between the BDN and the project products it uses but still keep them separate? Imagine a product breakdown coming out of the plane of the BDN.
What ought to be set in the style and layout of a BDN?:·
Left to right
Arrows or none
Top to bottom – better fit on a page, quicker on a flipchart, easier to read on a phone?
Defined columns or a continuum of nodes so the diagram stretches as long as it needs
Item names (personal dislike of 'Change', prefer 'Activity')
Coding – number the boxes, track it on a spreadsheet / database
How to show the importance of the connections between nodes (not what you've got, more what you do with it)
[See BDN Variations for examples]