“Contracts are the least powerful in getting people to do something. A contract does not fix incompetence.” Not my words, they come from Rajesh Mathur, but I completely agree.
When dealing with major crisis, like the 3 million pound budget cut I faced once, the first you have you have to remember is: Don’t panic, you are not alone.
They might be called an Architect or a Tech Lead or just “Bob” but I always work closely with a senior technical person.
“Well, we just got another kicking”. A group of us, representing technology, had just attended the regular programme board meeting with the business types. In the debrief afterwards the technology folk around me were despondent. In fact they were despondent every month after this meeting. They genuinely felt kicked. But I didn’t. I never did. It was almost like I experienced a completely different meeting to that experienced by my colleagues.
Leading software development often reminds me of what it must be like to ride a bucking bronco … with the added problem you have to go somewhere at the same time.
“Shonky” means poor or low quality where I come from. I realised it was a Kiwi phrase, or at least Antipodean, when I told my current UK based team to “give me a shonky user interface (UI)”. They looked puzzled, then laughed, then asked me what I meant, then laughed again, then adopted the phrase into the team vocabulary.
Aside from the entertaining aspect of my request, it does raise two questions:
- What is a Shonky UI?
- Why on earth would anybody ask for a Shonky UI?
A RAID log is used for tracking Risks, Assumptions, Issues and Dependencies. To be honest I see more similarity than differences between these. They are all about threat.
Assuming something means taking it for granted. In other words you’ve got a more or less conscious theory (or, less charitably, a guess) that something is going to happen. The trouble is that the assumption might not be true.
That screams risk. And as a programme manager or project manager you need to manage risk.
The most liberating day of my career was when I realised that, despite being responsible for the project I was running at the time, I actually controlled very little of what happened. That was the day I freed myself from the “fallacy of control”.
I can’t really control who does what. I can’t really control whether an individual does the work to an acceptable quality. I can’t control whether or not the product owner is going to change their mind about priorities. I can’t control whether the proposed technical solution turns out to be much harder than anticipated or just a dead end.
All I can really do is influence what happens in my programme/project. Spot issues quickly and react appropriately. Lean-Agile gives me the tools to do that.
A common English phrase is:
Don’t put all your eggs in one basket
This is sensible advice and is really suggesting a risk mitigation strategy (see Risk Management). The proverb, fairly obviously, means don’t put all your resources (money, time, energy) into the same activity, just in case that activity fails. Or, put another way, avoid single points of failure. Or, to use another common phrase, keeping your options open.
This advice applies in many situations and at many levels. For example:
- Royal succession
- Personal investments
- Portfolio management
- Programme or Project contingency
- Technical design
The Royals apply this advice in their efforts to have an "heir and a spare" to ensure succession.
At a more mundane level a sensible share portfolio has diverse investments to reduce the risk of failure of any one.
As my main interest is programmes, portfolios and projects I’ll concentrate on the last examples.