100 not out – on looking forward and being agile
(Ed. cricket metaphor, 100 runs is quite a big thing, although also a platform for game-winning double centuries!)
Since my first post, about Projects I have written 22 other bite-sized introductions to IT elements, the fundamental building blocks of everything you need to know, ever*, to understand the fundamentals of Information Technology.
*OK maybe not for ever, but the IT elements hopefully represent some relatively stable and long-lived reference points in the fastest moving of industries and human endeavours.
Post 50 looked backwards, considered reflective practice, project reviews and retrospectives, adapt-and-learn cycles and negative and positive feedback loops (heady stuff!) As I am here to stay now I think its time to look forward, using my centenary as a stepping stone to greater things. As the Chinese philosopher Lao Tzu (Laozi) said, a journey of a thousand miles must begin with a single step (wrongly attributed to Confucius).
As an aside, adding up these 100 posts, IT elements, glossary entries and other content I have written in excess of 100,000 words, enough for a largish novel, although short of the 110k which is deemed the ideal word count in the SciFi and fantasy genres.
It’s always good to look a little way ahead, metaphorically, for fear of walking into something unexpected! All projects, any non-trivial exercise, are likely to provide unexpected challenges, pitfalls or other blockers to onward progress, so by expecting the unexpected** you can try to be responsive and flexible/agile when circumstances change. This is the true mark of a project ninja – or short Italian plumber!
(**borrowing some terminology from psychology and the Johari Window, we in IT also refer to a spectrum of eventualities from Known knowns to Unknown unknowns, ‘Future circumstances, events, or outcomes that are impossible to predict, plan for, or even to know where or when to look for them’ – but this will need a separate post to explore further).
But what do you need to think about before you set off on your 1,000 mile journey? It can be a daunting prospect and can completely dis-enable any forward movement, playing into our natural human instincts to be cautious and risk-averse. There are good biological and evolutionary reasons why we might be nervous about embarking on something new. For example, fear of the unknown or the risks and the cost/impact of failure, which could be injurious to ones health, wealth and happiness. These potential negatives need to be weighed against the benefits, especially if doing nothing is a valid option. Business Analysts sometimes refer to this as analysis paralysis, the desire to understand and analyse everything to the smallest detail before starting anything, again there is a natural inertia to overcome to take that first step.
The problem of course is that not everything can be known in advance, and things change for all sorts of reasons that may or may not be controllable. This is one of the biggest challenges facing sponsors of work or Project Managers, in fact anyone involved in planning and defining IT and change projects; getting the right balance between the up-front planning and preparation versus, for example, a more laissez faire or suck it and see approach, or even a more forceful just do it directive from above.
Here are some of the things that might form part of an early project or program concept stage, or similar, and two ends of a spectrum of different approaches. I borrowed and adapted my categories from Robertson and Robertson’s Agility rating from the excellent book Mastering the Requirements Process (2nd Edition pp7-8).
Are you/you project/your organisation an Elephant or a Rabbit? An Elephant project is typically large, long-lived, possibly with external controls or contract obligations, I have used this as shorthand for a traditional organisation in terms of structure and methodology. Rabbits, however, are quicker moving, short-lived, more agile, and operate in an environment where light documentation and incremental and iterative approaches are favoured where possible. This polarisation is far too simplistic as both approaches offer opportunities for adaptation, compromise, and the adoption of a mix of appropriate techniques. Such a hybrid Elephant-Rabbit(!) is not to be confused with the Robertson’s Horse organisation. I digress.
|Governance||Put in place mechanisms to mobilise, structure and manage the project. This might include reporting (status/progress and problems), decision-making, escalation of problems, communication planning and quality measures etc.||Adopt light practices, in fact do nothing at all except to trust in the organisation’s culture and the [project/delivery] team dynamic|
|People||Build your project and team hierarchy from the top down, after all you will need the governance, planning and risk identification experts in place first, as well as the architects, project manages etc. won’t you?
Then, when you have everything buttoned-down (budget, requirements, designs etc.) then you just buy-in or acquire the right number of people with the specific skill sets required to do the work in the next stage.
|Get the right people in a team and point them at the problem! By right I mean motivated and self-directed individuals in a self-organising team. There is likely to be a mix of roles and skills, but also a recognition that everyone should work together to achieve the team’s goals.
Remember in Agile the team is the thing, so they must be supported to become as efficient as possible. Modern management is about clearing blockers, rewarding success, and if necessary rewarding failure!
|Risks||Identify risks to the ultimate success of the endeavour. On the basis that anything that could go wrong will go wrong. This is a deliberately pessimistic, or rather a ‘risk aware’, mindset to adopt in order to put in place measures to prevent, reduce, mitigate or accept risks and their consequences.||Erm, this is a tricky one. I refer you to the Golden Group of IT elements. An awareness and respect for Risks should be part of any project and any individuals approach to undertaking work. So I’m advocating that Rabbits do just enough active risk management.|
|Requirements/needs||Elephants document all requirements in a catalogue, model or requirements management tool, including for example, size, dependencies, priority (relative importance) etc.
Review and seek approval from all interested parties (stakeholders) before base-lining or ‘locking-in’ the project scope.
|At the risk of straying too far into Agile territory, agile Rabbits create a backlog of simple declarative statements, User Stories for example. A single fully-invested Product Owner is responsible for the backlog – things can move a lot more quickly without a committee!|
|Design decisions||Align the solution domain to your strategic architecture, establish design authorities, comply with design guidelines etc.||Address and resolve design issues as you go along, but be prepared to modify and rework (including refactoring code) as you discover more.|
|Plan||Create a detailed plan with tasks, milestones and dependencies. Use this joined-up view to understand the overall timeline, and any significant critical path activities or pinch points to be managed.
Use your plan to allocate resources to tasks and monitor progress, for example.
|Whenever you have enough of the right resources and tools, just start! OK, maybe that’s a little too hare(y), you could create a roadmap of high level chunks of development work and any mandated delivery dates, but really you can only make progress when you are building the things that need building … everything else is at best a necessary precursor or control, or at worst a waste of time and money.|
|Budget||Secure funding for Capex (Capital Expense items), people costs and other resources – will depend on how the charging model works and some sort of regulatory or fiduciary framework (probably).||So why isn’t budget one of the first things on the list?
It doesn’t matter how you plan and allocate costs, someone will want to know how much money you want, to convert into stuff (peoples time, equipment, consumables etc.) For true Rabbits this is too complicated and non-productive. Karl Marx may have thought in terms of controlling the means of production, but its more important for projects that they have access to the right resources when they are needed.
Let me return briefly to the sporting and other metaphors, and the title of this post.
To the next century
We have been remiss in leaving our cricketer, bat raised in the air, celebrating their milestone 100th run, and maybe looking ahead to the rest of the innings? It’s interesting to compare this point in time with the situation as she faced the first ball, or for that matter set off at the start of the journey, or kicked-off your project. What has changed?
As an aside, while Lao Tzu was thinking about the first step of a journey his contemporary in ancient Greece, Heraclitus of Ephesus (now in Turkey) was also contemplating travel:
No man ever steps in the same river twice, for it’s not the same river and he’s not the same man.
It doesn’t matter ‘where’ and to some extent ‘how’ you start, the journey will change both the dynamic environment and the people involved. As teams grow and mature and the project, hopefully, begins to hit targets and achieve successes, it must also deal with real (not theoretical) challenges, fix problems, and continuously check and balance performance. We as individuals also play a part in growing and learning from other mistakes, this is why mature teams and past experience is so important. And so, in our forward-looking journey we go full circle to the adapt and learn cycle and post 50!
A final word; Rest in Peace Stephen Hawking. I like to think he’s continuing his journey now floating somewhere amongst the stardust.
(c) 2018 IT elementary school Ltd.