Welcome to our blog, looking at all sorts of things related to helping you and your business perform better.
| M | T | W | T | F | S | S |
|---|---|---|---|---|---|---|
| « Jan | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | |||
Hello everyone,
Thank you for visiting, I know it’s been a while since anything was posted here, two things will now fix that.
Firstly my blogs will mostly appear at this new location and secondly I will once more be posting regularly again, in much the same vein as before. I hope you enjoy and please join in the conversation.
An amount has been written about the project management approach/target: OTOBOS – On Time, On Budget, On Scope. While there is merit in this target – which sort of percentage reflects success? Over a period of time I have been involved in recruiting and selecting project managers through my consulting engagements. Whenever I come across a project manager who claims to always deliver OTOBOS the following thoughts cross my mind:
Okay I am biassed by tending to work on complex change projects and programmes, but I don’t think I am alone in this viewpoint. It has taken me a while to work out that DSDM really is an OTOBOQ (On Time, On Budget, On Quality) methodology. I have never heard the term, but it feels like the right one. Surprisingly enough I would believe it if somebody had a 100% OTOBOQ record when managing DSDM projects. Perhaps 100% would be stretching it in the real world, but with a good narrative I could be convinced of a very near miss.
One way of describing this is to look at the following control parameters:
Atern is the current version of DSDM, this view comes from that method and I find it valid. Traditional projects try to fix the features and let the time and cost vary to accomodate this -leaving quality to suffer in the middle.
If you think OTOBOS it only gets worse, you are trying to fix Time, Cost and Features – Quality is the only thing left to give!!
DSDM says let the Features vary. Fundamental to DSDM is the use of MoSCoW prioritisation which classifies the business requirements into:
The detail is covered in another blog post. At a high level the project only commits to deliver the Must haves, the Shoulds and Coulds are negotiable (some say part of the trading space) and are used to keep the project to time and cost.
Only commiting to deliver the Must haves will protect the quality of the solution. Dropping the appropriate Should haves and Could haves when necessary will protect the time and cost budget.
Thus a well run DSDM project can deliver OTOBOQ. There is enough inherent flexibility. I am open to comments on OTOBOQ………………..
Tags: Agile, Atern, Cost, Could have, DSDM, Dynamic Systems Development Method, Evolutionary systems, Features, MoSCoW, MuSCoW, Must have, on budget, on quality, on scope, On time, OTOBOQ, OTOBOS, Prioritisation, prioritization, Project, Quality, Should have, Time, Waterdall, Won't have this time
Planning Poker is an estimation process that is entertaining yet surprisingly effective. We have previously touched on more traditional approaches like 3 point planning. Planning poker enjoys popularity in Agile projects, but there is no reason why it should be limited to this type of project or even limited to estimation within a project.
The process appears to have been created by James Grenning back in 2002 and most widely popularised by Mike Cohn and Mountain Goat Software.
For those coming from an Agile perspective (e.g. DSDM, Scrum or XP) the article assumes you have created your user stories (could be story points, requirements or whatever else you are estimating) and prioritised these (we recommend the MoSCoW approach).
The Planning Poker process is quite simply as follows:
So the process is quite simple (okay there are many subtle variations on the above process, but they all retain simplicity), but the power lies in getting everyone together, gaining different viewpoints, generating meaningful discussion, improving up front understanding and agreeing on an estimate. It also has a positive effect on the team and shared commitment. The optimists and the pessimists can put their cases forward, the genuine “gotchas” are identified up front and clarified rather than ignored and lapsing into a bout of “I told you so” and “we didn’t know”.
Tags: 3 point planning, Agile, Atern, DSDM, Dynamic Systems Development Method, Estimation, Evolutionary systems, MoSCoW, OTOBOQ, OTOBOS, Planning Poker, project management, Requirements, Scrum, Story points, User stories, XP
This one came up again the other day – the discussion around how to earn greater respect from your internal customers. There is a very handy piece of Gartner analysis that helps with this. It’s not new, but it’s still highly relevant.
It looks at the issue of an IS department / organisation and its credibility with its customers. There is a lot of overlap with models like capability maturity, but one aspect we like about the Gartner one is the external focus. Maturity models by their nature tend to focus on internal process – this model considers the perception of the customer. Neither viewpoint is better than the other, together they can be very powerful though.
This credibility journey is broken down into 5 stages:
There is a wide range of tools and techniques that can be used to move a department up along this curve. It is also worth pointing out that this is a business-wide rather than just departmental issue and does not have to be restricted to IS departments only. If the IS organisation lacks credibility then the business is unlikely to be able to realise the full benefits available from IT. From a departmental standpoint it just serves to make every day more of a struggle.
We believe this is a good, portable model. How credible is your department with its internal customers? How credible is your business with its external customers? What are the levers you can use to move your self up through the levels and earn the respect of your customers?
Tags: acceptance, capability maturity models, CMM, credibility curve, Gartner, respect, scepticism, trust, uncertainty
Many of you will have heard of MoSCoW prioritisation (though many may not). We have recently found it being used more widely, and also being abused more widely as a consequence. Hence the thought to write a short article to clarify the approach.
MoSCoW is an approach to prioritising project requirements that belongs to the DSDM consortium. For those with an interest in history, the term was created by Dai Clegg of Oracle, but he later donated the IPR (Intellectual Property Rights) to the the DSDM consortium. For those with no interest in history I should have warned you to skip the rest of that sentence.
We won’t go into the detail of the DSDM approach to Agile project delivery (though it is very good) as the technique stands alone quite well. MoSCoW is very good for getting to the heart of people’s priorities. Essentially it proposes you agree to put all requirements into one of 4 buckets:
You might also see why some purists say it should be MuSCoW, but that’s splitting hairs in our view.
At first sight this might look a lot like a lot of other prioritisation approaches – the real difference lies in two areas:
It is vital to bear in mind, this is not “Would like to have” nor is it “Won’t Have ever, ever, ever”, the emphasis is on “this time”. All too often when we go in to help with a troubled project, one key area to address is the scope, looking for requirements that aren’t really needed right now, but are holding everything up. There are all sorts of reasons requirements go into this bucket – in no particular order some of these are:
There is also a key nuance in the use of MUST – defining the Minimum Usable SubseT of the full set of requirements. All too often the concept of Must Have is dominated by lobbying, hobby horses and the whole idea that at some point you will have to trade some requirements, so you might as well go in high.
In the DSDM approach these are really the show stoppers. If you fail to deliver one of these requirements then at least one of the following will apply:
So basically if you ask the question “What happens if we fail to deliver this?” and the answer is “Cancel the project” then you have a Must Have. Otherwise you are looking at a Should Have or a Could Have.
For those involved in Agile approaches, it is important to note that a requirement can have an overall project MoSCoW priority as well as an iteration or increment MoSCoW priority. But that is too much detail for today – we can return to this.
Should Have requirements are still important, but do not pass the vital test above. It would be painful to leave them out, but your solution would remain viable. There is probably a workaround, expensive and painful though this might be.
When you evaluate the level of pain, the number of people affected, the cost and impact of the workaround, the level of benefit attached to the requirement, then you can differentiate between Should Haves and Could Haves. There is no golden rule, just some good old common sense and frank, grown up discussions with your stakeholders and sponsor.
And finally, don’t get too bogged down in the idea this is just for Agile projects coding new software solutions. It is an approach you can readily adopt to any situation requiring you to prioritise a future workload.
For those with an interest in linking MoSCoW to project estimation read our post on Planning Poker.
Tags: Agile, Atern, Could have, DSDM, Dynamic Systems Development Method, Evolutionary systems, Extreme programming, Minimum Usable SubseT, MoSCoW, MuSCoW, MUST, Must have, OTOBOQ, OTOBOS, Prioritisation, prioritization, Scrum, Should have, Won't have this time, XP
We have referred before to “wicked problems” (in the post on Unproductive Busyness) and promised to elaborate on the topic – so here we are. Given the broad coverage of this area we are going to focus on the failings of traditional project management methods when it comes to dealing with wicked problems.
We believe the phrase was coined by Professor Charles Churchman of the University of California, Berkeley back in the 60s but remains relevant today. It was then further developed Horst Rittel and Melvin Webber (also of Berkeley), I have to confess to arriving late at the party with Professor Mike Pedler from Henley Business School introducing me to the idea.
Essentially the approach looks at the uncertainty involved and level of collaboration needed to come up with three problem types:
In a previous post on Puzzles, Problems and Messes we looked at the importance of not trying to solve a “mess” but first clearly defining the problem. However in business life many problems live in that awkward middle ground between the ill-defined mess and the well-defined problem. This is where wicked problems come into play. However, first, let’s look at all 3 types:
Low levels of uncertainty, little need for collaboration but swift action required. Typically suited to command and control approaches rather than traditional project and programme management.
Mid levels of uncertainty and collaborative approaches need. These tend to be amenable to planning and probably form the majority of problems addressed through classic programme and project management. We are increasingly living in a world where everything is becoming a project and everyone calls themself a project manager. Success is measure by the ability to deliver On Time, On Budget and On Scope (OTOBOS) or some other, similar combination of factors. We are led to believe that project failure results from project management failure, if only the scope document was properly written and approved; if only the right products were defined; if only the right project controls were used then all would have been well. This therefore leads to the dangerous view that good project management will result in a successful project.
Whenever I encounter a project manager with a 100% track record in OTOBOS delivery I suggest they have a selective memory or are a truly tame project manager (i.e. they only manage projects that solve tame problems).
Here high levels of uncertainty exist and high levels of collaboration are needed. Further learning and distributed leadership are required to resolve. More and more business projects fall within this area. Even in the technology project space most of the low hanging fruit was picked years ago – systems are highly interdependent, technology and processes are intertwined with working practices and job security. It takes a lot more than good project management to deliver project success in this area!
There are 10 characteristics of wicked problems usually attributed to Horst Rittel and Melvin Webber:
Tame project managers not needed here, wicked project managers welcome! In fact you could argue that recruiting a good wicked project manager is a wicked problem. In order to achieve success in finding and delivering good and better solutions they must have made mistakes on the way. They will have exceeded budgets and delivered off specification and not on scope but ultimately have delivered successful outcomes. In other words a really good wicked project manager has many similarities with a really bad tame project manager.
Can we promise you a simple and elegant way to solve wicked problems and to deliver wicked projects? No, but we will be posting more on things that can be done and certainly welcome comments and additions to this post!!
Tags: business change, critical problem, management, P3M, problem solving, programme management, project failure, project managment, tame problem, wicked problem
Cloud computing seems to be all the rage at the moment. There are many good reasons for this and others that will just prove to be hype over time. However there is not doubt that this could be as disruptive to the software industry as iTunes, Napster and others are proving to the music industry.
In this article we will outline the 3 key categories of cloud computing – all ending in “aaS” (which stands for “as a Service”). This will give us a good starting point from which to discuss the larger and more radical points alluded to above later.
By the way the term “cloud” originates from the cloud symbol used by techies to represent the Internet on the majority of diagrams.
Cleaning as a Service.
No prizes for guessing we have made this up (there are really 3 types, not 4). But it should help demonstrate the service principle without any IT jargon. For those who want to dive straight in, jargon and all, then skip to SaaS below.
Imagine a world where you do your own cleaning, you bought the vacuum cleaner and pay for its repairs and replacement, you buy the bags, cloths and cleaning fluids and other items as you go along.
You decide there must be a better way, you discover the kids are pretty keen on this and want the pocket money so you pay them to use your vacuum cleaner.
You discover they are not so good at the job (more interested in playing with the gadgets than the business of cleaning) and keep forgetting bits.
So you decide to outsource to a cleaner but find you are still providing all the tools and consumables and probably find yourself feeling embarrassed and doing cleaning before they arrive.
Then a salesman turns up and you are persuaded to buy a robotic vacuum cleaner that does the cleaning by itself. But when it breaks down it’s a pain to fix. Then somebody offers you a self-healing upgrade so the vacuum repairs itself (they claim) and it’s just getting too confusing.
And so it goes on until you find somebody offering CaaS – you just pay them a monthly amount and they do all the cleaning. provide all the equipment, maintenance and consumables and, heck, they even bring their own electricity and water.
You just order the service you need. The Spring Cleaning service please, the Window Cleaning Service please….
And so it is with cloud computing – you are just buying a service and letting somebody else worry about all the rest.
Software as a Service.
Here you are paying for a service that covers everything needed to provide the software (the servers, internet connection, maintenance, licences etc. etc.) Salesforce.com is a pioneer in this field and a classic example of SaaS. A typical feature of a SaaS offering is that you pay a fee (hopefully small) per user often starting with a small number (e.g. 5 users) at a price you could never match if you were to build and buy your own servers and run a deployment project to get it all live.
Platform as a Service.
Here you are paying for a service that covers everything to provide the platform to run your service (servers, operating systems, internet connection etc.) but not the software itself or at least the development effort to create the final software.
In this case it is often about software development, you have the developers but don’t worry about providing everything else they need to do the job in house. Often this services includes presenting the software to customers via a website when it is live, so you really are just doing the design, development and test bit in the middle.
A good example of this is Google AppEngine. You start out small, but if your application suddenly becomes massively popular you just buy more storage and bandwidth as you need it rather than panicking and running to your hardware supplier.
Infrastructure as a Service.
Here you are paying for a service that covers the infrastructure (often referred to as the “tin”). So all the servers, storage, networking etc. are part of the service but none of the software.
A good simple example is Amazon ECS which provides on demand servers.
Some simpler services are just about on demand storage.
So what things really unite all of these offerings as cloud services:
Sometimes people use the term “utility computing” imagining that you buy computing much as you buy electricity or water from your utility company.
And to top it all we haven’t even got the space to look at the types of cloud (e.g. private, public, community or hybrid). Perhaps another day.
Tags: cloud computing, elastic computing, IaaS, Infrastructure as a Service, on demand computing, PaaS, Platform as a Service, SaaS, service orientation, Software as a Service, utility computing
Now that the election is behind us I have found myself surprised by just how alien the concept of coalition is to so many people. Luckily for the country the two relevant (i.e. Lib Dem and Conservative) leadership teams seem to “get it”. By this I am not saying whether or not it is the “right” coalition but merely thinking about what it takes to make and maintain an effective coalition.
Then it occurred to me that I should not be surprised. This lack of understanding is a fundamental blocker to successful business change. Thinking back to Kotter’s approach to successful change the second stage is build the “powerful guiding coalition”. So this set me thinking about lessons we might take from this recent coalition forming process.
The word “coalition” comes from the Latin coalescere, meaning to join or grow together. Typically we think of a coalition as an alliance that forms in political or commercial contexts. This can be approached from so many angles, but one interesting approach is proposed by Steven Brams and he has looked at the importance of the formation process. He has proposed two broad coalition types:
Fallback (FB): Players seek coalition partners by descending lower and lower in their preference rankings until some majority coalition, all of whose members consider each other mutually acceptable, forms.
Build-up (BU): Differs from FB, in that only majorities whose members rank each other highest form coalitions.
They conclude that the Built-Up coalitions tend to be more stable since people tend to be with the partner they really want to be with rather than ending up with other partners (second best or worse). In many examples it appears the final stable coalition starts with smaller BU coalitions who subsequently coalesce into a larger, majority coalition.
In the case of the general election it is interesting. It would seem that for the party leaders the current coalition is a BU alliance (with first choice partner) and that negotiations with Labour were the start of an FB coalition – or perhaps just a negotiating ploy. However it appears there are very many Lib Dems and Tories who see the current alliance very much as FB (each preferring a Labour/rainbow coalition and no coalition but minority government respectively). Whatever the intentions behind the Labour negotiations it certainly made it clear that Labour did not want to talk, and that those who preferred Labour were left facing an FB coalition or no coalition at all.
There is the sense that the Lib Dems are in fact the initial BU coalition, albeit formed many years back. This further coalition with the Conservatives does put some pressure on the initial coalition. It would appear that there were several opportunities for opponents to have a say, the Lib Dem MPs, the Federal Executive and even a special party conference (which I understand was not technically necessary, but held nonetheless). So the engagement has been wide and effective, though hurried through as a change many people have had the opportunity to scupper the deal and so far Clegg has carried his party with him.
What can we take away from a management perspective? Companies implementing change will often try to brow-beat people into a grand coalition. Additionally they often won’t open things up to key stakeholder groups thus denying them a chance to air their objections and concerns publicly. As a result many managers and teams will see themselves forced into an FB position, which would appear at best a semi-stable arrangement and probably worse than that when many stakeholders are disgruntled. Much better, from this analysis, is to build small, but stable BU coalitions and then work on developing real common ground between the smaller coalitions until you have the majority support you need for a successful transformation. Remember, too, that with stakeholder mapping it is often worth plotting groups as well as individuals.
This might take a little longer in the early stages, but is the route to effective and lasting change. While so much of the press was haranguing Clegg and Cameron for taking so long I couldn’t help but wonder at how quickly the coalition seemed to be pulled together.
There is a further interesting perspective. In business senior managers often take the “burning platform” for granted and assume everyone will be swept along with the new transformation. Even as the press and the markets seemed to be fanning the flames into inferno proportions, many players in both parties saw no pressing need for coalition and would have preferred to go it alone – doing the same as they had always done. Creating that “sense of urgency” (Kotter step 1) can also take longer than first expected, but is key to “making it essential”. Maybe it was the prospect of the Queen flipping a coin that made the difference………
Tags: 8 steps, build up, burning platform, business change, coalition, coalition partners, fall back, general election, guiding coalition, kotter, leadership teams, leading change, make it essential, sense of urgency, stable alliances, stakeholder management, stakeholder mapping
With only a few days left until the UK general election 2010 we thought we would take a slight diversion from our usual themes and share this visual election opinion poll tracker. Not a complete diversion as this is about is big as it gets when you are doing an external analysis using PESTLE (as we briefly described in an earlier article) or other similar approaches.
We hope you enjoy it – might even give some useful hints on how to build the next management dashboard……
The poll data is provided by ComRes, YouGov, ICM, Angus Reid, Populus and MORI. The poll tracker also includes a seat forecast, Betfair overall majority forecast and the option to embed this political poll tracker in your websites.
Tags: Election 2010, External factors, PEST, PESTLE, Politics, STEEPLE, STEP, strategy
I have been doing some work with the team at EvocoGreen on developing a hierarchy of green behaviours – and we have produced this:
This is business at its simplest and most raw. The pursuit of profits is a task far too important to be diverted by concerns for pandas, polar bears and far away ice caps (just look at how much snow we had this winter!). There is often a successful meeting between the bottom line and NIMBY(Not In My Back Yard) blinkered consumer behaviour. While the customer might espouse green values they often cannot resist a bargain, and turn a blind eye to the pollution that has been outsourced to some offshore, probably third world location.
The climate is saved through happy accidents rather than design. Companies seeking to cut costs and become efficient often cut power consumption, waste and packaging in pursuit of profit rather than the green agenda. They may, or may not, claim green credentials retrospectively (moving themselves up in the hierarchy to ‘Visible Green’ in the process) but do make a positive environmental contribution nonetheless.
At best these companies are making a real green contribution, at worst they are proudly wearing their eco-bling in public. Their offices will have some solar panels or a wind turbine and their vans will have carbon neutral stickers clearly visible through their exhaust fumes. The joy of being in this zone is that often an organization does not change their behaviour; they just pay others to change for them (through carbon trading, outsourcing or off-shoring their least green activities), and bask in the resultant green glow.
This is often a form of product differentiation on meaningless attributes. The companies involved probably haven’t improved their products or the lot of the planet in any meaningful way, but you would never guess that when you listen to the PR.
Arguably the Visible Greens might make less of a real contribution than the Accidental Eco Warriors in terms of real environmental impact.
However the negatives should not be overstated to the detriment of those companies making a real contribution.
These companies are seriously looking at green options, doing some proper sums and trying to gain genuine competitive advantage (not to be confused with good PR and marketing hype) through their green actions.
They are often quite subtle in their approach, for example Nokia have a strong track record in reducing toxic chemicals, recycling phones, sourcing energy from renewable sources but its mainstream marketing focuses on traditional product attributes.
Kenco with its 97% less packaging campaign has clearly struck a chord with consumers, but the sums still need to be done comparing the use of recyclable glass versus the new, hard to recycle foil and laminate.
Ben and Jerry’s probably live here with their “lick global warming” campaign and media coups such as the 1,100 pound baked Alaska for Earth Day back in 2005. High profile marketing perhaps, but with a sense that the company is sincere enough in its aims to earn more than Visible Green status.
Pioneers have always been a diverse and eccentric bunch and the green ones are no exception. On the one hand you have companies blazing a trail in thin film solar, on the other the likes of Toyota with the highly successful Prius. While there are some who might argue that a Prius is eco-bling with its embedded carbon, toxic chemicals and the like, but Toyota is investing vast amounts of money into developing the market for low energy cars. If the numbers do not fully stack up for the Prius today – the truly green cars of the future will owe a debt of gratitude to Toyota for the commercial gamble it took.
New generation solar panels increasingly depend on materials like Cadmium which is highly toxic (e.g. to aquatic life).
One of the biggest problems in assessing the environmental impact of actions is that of taking a properly holistic view. This has been alluded to in the sections above and there are so many variations on this theme. Take packaging: what relative value do you attach to reduced packaging vs. recycled content vs. recyclability vs. miles travelled vs. biodegradability? Add to that there is no universal view – the level of recycling in the US and Germany is vastly different, so similar initiatives could have vastly different environmental impacts.
Take bio-fuels: chopping down vast swathes of Amazon rain-forest in order to grow bio-fuels may actually create a carbon debt that may not be paid back for hundreds of years. There is the balancing act between short-term pain and long term gain. The case of the Prius was mentioned above. Tetra-Pak has invested a lot into recyclability and recycling of its foil-lined cartons, but availability of recycling points is still limited – what is the impact and how do you rank the investment. Some would call it pioneering others would call it a cynical marketing abuse of the recyclable emblem.
Take public transport, an empty bus pollutes far more than an empty car and an empty bio-fuel bus may fare even worse. More effective and holistic measurement will help move companies up the green hierarchy.
Tags: accidental eco warrior, Competitive green, Customer behaviour, Eco pioneer, environment, Green, hierarchy, polluting, polluting for profit, strategy, Visible green
Recent Comments