A few days ago, as I walked across Tower Bridge in London, someone pointed out that a new building, named the “walkie-talkie” on account of its eye-catching shape, was causing street-level damage as a result of the sun rays hitting its concave glass surface (it’s true!). It made me think how complex projects can be perfectly planned on paper but then encounter “burning” issues upon implementation.
Small projects tend to be about just “getting it done”: little mistakes can easily be rectified on the way. For larger projects, top-down vision, clear direction and well-planned execution are a must; however, it is not uncommon to witness a disconnect between the ideas of architects and the practical experience of the project teams. Getting the balance right can be very difficult.
In the world of software development, what always struck me about large projects is how much elapsed time, not to mention person-days, a requirements-gathering effort could take, only to find that – once the analysis is complete – a significant number of variables have changed (not to mention the ones never considered).
Is there a perfect solution? Unfortunately, not that I know of. But I have experienced a situation which provides insights that others may find useful.
One of our clients was conducting a strategic effort to deliver an enterprise-wide planning tool. In parallel, they engaged us to develop a planning system for one of their divisions. The system was considered tactical and destined to be eventually replaced by the strategic solution.
A virtuous cycle emerged: the division that was working with us participated to the strategic design sessions with a clear sense of purpose and urgency; they were quick at providing new feedback so that we could adapt the system to incorporate the latest requirements. They were chasing a dual goal: to rollout their tool ASAP and to ensure that moving to the strategic solution in the future would be painless.
The unexpected and welcome outcome for us was that, by the time the strategic design had been fully agreed, our system became, with a few enhancements, the strategic solution.
The real bonus for the client was that, as every stage of the design phase was signed off, a subset of the final intended ‘audience’ were already busy setting up and testing the new process, thus able to more actively contribute to the design sessions.
Cost-wise, the delivery of the tactical system in parallel with the strategic analysis was marginal. In hindsight, the benefits for the client turned out to be significant. What may come as a surprise is that the virtuous interaction between strategic and tactical did not come by design but was dictated by circumstances, i.e.: the pressing requirement for a division to have a tool while the strategic solution was in the making.
Was this any different from“proof of concept” or “prototype” systems, which are often an integral part of the design phase of a large technology project? I believe so, primarily because a real, albeit localised, need had to be satisfied. Having stakeholders with ‘skin-in-the-game’ from the outset was a key factor, driving change rather than passively resisting it. And nobody got burned.