I heard Hofstadter’s law being quoted by programmers and Project Managers and it caught my attention.
If you’re a ‘Big Bang Theory’ fan you’d be forgiven for thinking that Hofstadter’s law is “the more, you try not to appear like a geek – the more charmingly geeky you’ll appear”. (I love Leonard! If Penny ever gets tired … sigh!).
If I’m honest, I had heard of Hofstadter’s law but to be certain, as with most things these days, I Googled it.
Actually, Hofstadter’s law was devised by cognitive scientist Douglas Hofstadter and it goes, “It always takes longer than you expect, even when you take into account Hofstadter’s Law”. What that means is that any project will always take longer than expected – even when you build time for overrun into your project. The Project will simply overrun the extra time you allowed.
It’s often quoted to excuse Project delays.
And, in my honest opinion, it’s a complete fallacy.
For a start, when Hofstadter conceived his law he did so in relation to a Chess playing programme and from the paradigm of technology as it was in 1978. It was predicted that within a decade a computer could be chess champion but by 1988 that was still the forecast, hence the law. So, unless your project is designed to deliver a chess champion Hofstadter’s law is pretty irrelevant.
The reason why it’s irrelevant (or at least should be) can be summed up with one word – scope.
If your Project ain’t got scope – it ain’t got hope. It’s your best defence against chaos.
IT Project teams often don’t bother defining the scope of their project, they want to get on with planning and execution. Planning and executing what? How do you know if your Project hasn’t got scope?
These moments, before you roll up your sleeves and get on with it, are vital to the potential success of your Project.
When you define what your project will do and, ultimately, what ‘done’ will look and feel like you take a massive step toward designing out failure. When you define the scope of your project you create lines of accountability and clear expectations. You create the boundaries within which your project will operate and you begin to engineer your best route to success.
At this stage of your project you are dealing with ‘what’ and ‘why’ and you should pay more than casual attention to these to get the most out of planning of your scope.
For instance, your IT Project mission may be to consolidate your data centre operations. Well, that’s a fine ‘what’ and it will define your scope to some extent but when you ask ‘why’ you really begin to lay some project foundations. When you address the ‘why’ you align those project foundations with your business strategy.
You may want your consolidated data centre to support strategic growth and expansion, for example, with no business disruption during the project. You might then want to put some numbers on this … ‘potential for capacity to grow by an additional 40%’, for example. You might define what ‘no business disruption’ means in real terms – are business hours 9 to 5 and is the rest of the 24 hours fair game, for instance.
The more you really drill down at the ‘what’ and ‘why’, the more you’ll be able to stay within the scope of your project. The more specific you are the better you will be able to forecast realistic delivery and budgets making estimation a science rather than guesswork.
Make sure you refer back to the original paperwork, the blueprint or proposal for the project where you should find the answers to any questions that your scope explorations throw up, then when you are sure that you have it clear in your mind prepare a ‘scope statement’.
The scope statement is a summary of what the project will achieve. I think of it as a compass for the project team to ensure that they heading in the right direction in alignment with the objectives and the business case for the project.
Your scope summary should also map out the hard-wired elements of the project. If there is a product launch date then that is a pretty crucial thing to include in your scope documents but similarly there may be what my colleague Jamie refers to as ‘low hanging fruit’, easily useable resources that it would be crazy not to make part of the project DNA should be included in your scope.
Once your scope summary is written, you can start planning for the fun part and make huge strides towards implementation. Working out return on investment (ROI) based on reliable project cost figures. Plotting timelines for the project accurately, remember, you took the time to define what ‘no business disruption’ really means so you know when your team will be working evenings and weekends and what that will cost and how long it will take.
Cost and Time, those two serial killers of IT Projects are brought to book by scope. Powerful tool. eh?!
When you have scoped out your project, the ‘what’ and the ‘why’, you can move on to the ‘how’ and really start to move towards that start date.
The ‘how’ part of your planning is made easier by your scope spadework. Imagine how much more difficult it is choosing the right methodology to apply when you don’t really know what it is that you’re applying it to.
If your scope’s ‘what’ and ‘why’ are the foundation then the ‘how’ is the framework, the structure, the skeleton of your project. Priorities and hierarchies, breakdowns of activities required, allocation of resources, etc, etc, all benefit from that original decision to commit to project scope.
Most projects that I come across that are in trouble did not give enough thought to scope. To put it another way, just about every reason for project failure can be mitigated by proper scope documents that can be referred during the project lifecycle.
It can be hard work.
It can give you a headache.
You do have to ask hard questions.
You don’t have to do it alone.
The Project Management as a Service market has plenty of solutions for you to buy in whatever the maturity of you own scope skills.
Maybe you are designing software designed to defeat a chess champion. If you are then good luck with Hofstadter’s law and, for that matter, time travel because Deep Blue beat Kasparov in 1997. For the rest of us, with deliverables and stakeholders, business outcomes and resources that can all be measured there is no excuse.
Start your next project with an effective scope in place and your project won’t take longer than planned nor will it cost more than planned either. It will be a perfect representation in real time of the visualisation everyone had at the outset.
Learn more about how Stoneseed’s Project Management as a Service can give you access to project management staff, resources and tools at a flexible and predictable cost via a fully structured managed service.
Find out more about Project Management as a Service from Stoneseed
