Why model strategically? I'm looking for some way of preparing thought at the stage of the business case (the full one not the bean counter's profit statement) or the research proposal. We need to know what's connected to what, and what gaps exist. We need exact knowledge of uncertainty. We don't want to commit to tasks and sequences yet, but we do want to shake out the structure of organisational relationships with the underlying technology.
The tactical level is well-trampled, principally by the Gantt chart. For discussion of some of its deficiencies and some possible alternatives, we'd better Ask Tufte. However, the strategic, beginning level of projects is airy fairy whiteboard stuff, the fuzzy front end.
Snagged from a somewhat random US army document about process modelling.
This is the commonly used ICOM model, a Lego brick of many process model formalisms. I'm trying to think how it could be used in a strategic-level project modelling system.
Inputs and Outputs of generic activities are obvious elements to model, but we don't want to imply that a task is done once. Rather like a diagram of body parts, we want to infer circulation and iteration of knowledge and materials between connected parts.
Instead of Mechanisms and Controls, we can use the vertical faces of an activity node to represent Resources and Constraints respectively. We can utilise this in a mapping scheme to show contributing organisations arrayed along the base of the diagram and customer/external organisations in the upper part.
Ideally I'd like to connect this to hard data (tables) about the connectedness and certainty of each of the elements. I'd like to take the drudgery away from the drawing aspect, and have the ability to do basic traceability and completeness analyses on the strategic model.
Sound good? Next week I'll draw a few.
2 comments:
I'd actually been thinking about this problem too. I have to give a presentation next week at the 'airy-fairy' strategic phase and whilst I know what information I want to get grips with I'm really not sure how to model it in an efficient manner.
My mind is stuck in thinking about Gannt charts (due to the aesthetic simplicity of decoding a 'timeline' but I know that's not suitable).
I think the keys are
- there is no timeline – a deterministic series of tasks – at the fuzzy front end. To represent the possibilities of the project as such is often unhelpful.
- representations should allow the quality of information to surface. At the project-forming stage, it's vital to know what is known vs what is unknown. The quality of information – such as the existence of a contractor – should go through a series of maturity levels, from Suspected to Verified. A helpful model should demonstrate this.
At the conceptual phase of a project, effort should be focussed on forming (and keeping flexible where necessary) the project strategy and scope in relation to its external and internal environments, not processing of detail within tasks. That's not to say Left Shift is bad, far from it!
This phase should not be characterised as airy-fairy. The focus is on higher-order entities than tasks. However, they should still be managed definitively.
Post a Comment