Those who have worked with me will know that I can sometimes be as frustrating as hell! I work by a let’s get it done mentality; rules be dammed. Why, I wonder, follow the rules when the bureaucracy actively prevents humans acting reasonably to work together to bring a project to fruition. Trust in enlightened self interest I say!
The fear is, of course, that at some point another’s view or agenda will take precedence, diverting the project from it’s original goals. We spend weeks and months defining and tying down, the how’s to ensure that everyone knows what they are responsible for. These rules are ultimately designed to mitigate the financial risks of the organisations we work for.
There are real constraints though: a goal or vision must be defined and measurable, the outputs must be declared and the outcomes must be measured. Project plans, milestones and checks and balances exist to ensure the successful delivery of the project outputs. After all, we are ultimately constrained by time or money and usually both.
By measuring the project at the vision or goal level we are able to determine if a project has succeeded or failed, without having to legislating for every individual action. Conversely the act of legislation prevents creative thinking, and learning, from happening ensuring that efficiency and positive feature changes are not discovered.
By denying the activity of continual discovery we are unwittingly adhering to the fallacy that we can accurately predict future wants and needs. I.e. Future efficiencies and better functionality cannot be explored as the problem space is illuminated because they weren’t declared ahead of time.
Where change is recognised, the business case is presented and a change request is created. Usually though this is a one way street. Features are taken out while project expenditure remains the same and additions always increase the project expenditure. Reinforcing the need to restrict change as “scope creep” is always presented as having a negative impact on a project.
I therefore suggest creating an feature/output trading scheme. Whereby all change regardless of the impact is assessed this includes the financial impact; Good or bad. If the impact is positive (for the project) put the balance in the project bank, for when something goes wrong. If it’s negative and you have something to spend, spend what you have. If there is nothing in the bank to spend, you at least have the data you need to decide the next step.
For example
It is discovered that feature a/output b is no longer needed. An impact assessment is drawn up showing the impact of not doing it, including financial saving. If agreed, It’s withdrawn and the saving is added to the project balance. Later if feature c/output d is required, an impact assessment is drawn up showing the impact of doing it. If the change is agreed and there is a positive project balance the costs are transferred and the change is committed. If there isn’t a project balance a business case us drawn up and more fund requested with the data from the impact analysis used to support the request.
I’m in no doubt that this simple idea is unofficially in practice in most projects. Except, that when something goes wrong and you need to understand who’s financial responsibility it is (I.e. Who’s to blame) the whole house of cards can comes tumbling down. As it is unofficial: Change, financial impact and trade offs are not captured and therefore the problem can not be measured against the original brief.
By acknowledging the reality of the situation in a transparent, documented approach we can embrace change, allow new discovery to flourish knowing that at a later date, as long as the bank account balances, everything is okay.
p.s. for any agile practitioners out there i know an agile approach can facilitate change as described above. Agile isn’t a pervasive methodology for most of the clients i work with.
Matthew Goddard 