I have been trying to focus myself on benefits and achievements whilst preparing my CV and other personal marketing materials, but I have suddenly realised how valuable benefits can be when defining requirements.

An acronym many people use the help them define benefits is “FAB” – Feature, Advantage, Benefit. The Feature is the activity that I carried out as part of my role, the Advantage is how this improved what was there before, and the Benefit is a tangible description of how the company or people’s working lives were better thanks to my achievement. It’s not always necessary to write out the Advantage, because it is usually very similar to the Benefit – however that act of describing the advantage helps identify the benefit in the first place.

But hang on, why are benefits important in a CV? Well, to borrow an expression from sales and marketing, people buy benefits, not features. They buy the relaxation of being by the pool on holiday, not the model of plastic sun lounger they will lie on. Likewise, people hire you because of your past achievements, not because of any lines in your old job description.

So bringing this back to Requirements Management, how does this fit? The requirement is the Feature. Generally we have defined it as a requirement because we have identified it as one of the detailed mechanisms we can add to the overall process, in order to ensure we gain the advantage that delivers us the benefit. This is great, because when we come to compare the deliverables against the design requirements we know that if we tick the box to say “yes” that feature is present, we then know we will achieve the benefit without having to look.

So why should we care about benefits when defining requirements. What’s the advantage of justifying why the requirement is there? Well, let’s take the worst case scenario during testing when you fail to get a tickbox against that requirement – oops! What do you do now? Do you have to go back and rework your deliverables until you fix them by making sure the specified feature is present? Well, not necessarily!

Remember that features such as requirements are only there to deliver benefits, and if the benefit has already been successfully delivered via other features that are there, maybe you don’t really need that missing feature after all.

If you know which benefits depend upon a requirement, then its easy to work out whether fixing that requirement is worth the effort. If it can’t improve the situation, because the benefit is already fully present, then it may have seemed like a handy feature at design time, but it’s not worth going through the effort of fixing up because it will not make any difference!

Risk management conditions us to feel it’s vital to be cautious. We must plan properly, test thoroughly, document clearly and deliver with control. And these are principles that have stood innumerous projects in good stead.

But could there be another way?

Is there a devil’s advocate that appears in the form of a service crippling crisis?

When the lights go out a dust-covered candle stub shines as a bright beacon…

Because when nothing is working, you have nothing to loose!

I have witnessed occasions when technical solutions have been crash-delivered before they were properly ready in order to fix operational issues, when it has been worth cutting corners and dealing afterwards with the minimal amount of clean-up required. These urgencies have actually been to to mutual benefit – saving the project’s time and the operational team’s bacon

I’m not saying that project management principles or service delivery best practice should be abandoned in favour of cavalier practice, headstrong anarchy or a do-now–think-later mentality. Implementing deliverables when they are not properly ready should be saved for extreme emergencies only.

However that raw, needs-driven approach that characterises critical failures points to the practical idea – that extreme pragmatism could be applied in a measured way for slightly less impending events.

Perhaps it could be a valuable habit to always do a quick cost-benefit evaluation on each facet of a large body of work. Sometimes “because we’ve always done it” or “because the normal process says we HAVE to” are assertions that beg to be questioned in the name of good sense. Measure each risk objectively, in the grand scheme of things, and question whether those test criteria, document sections or even requirements actually justify the amount of effort they will consume. Nice to have? But at what price?!?

If you tip the playing field up far enough then you’ll find it easy
to kick the ball towards your own goal and still score in your opponent’s net. And crises show clearly how extreme people will allow pragmatism to be, when there is enough at stake.

Towards the end of a project to outsource a large section of a company’s infrastructure I learned that a previous IT Director was very proud of her decision a few years beforehand to insource much of what we were putting back out. Looking into the reasons for both of these transitions you could conclude that there is a right time to have stable operations run at a low fixed cost, and there is a right time to increase the cost, and the risk of cost escalation, in order to allow rapid change by removing barriers and pooling knowledge tightly within a highly skilled team.

Well if both are valid at times, could they not both be valid at the same time? Is there not a case for “rightsourcing”?

The strategic and more-or-less stable systems can be managed in the background by a supplier, only needing major attention for periodic refreshes that replace outdated or capacity-bound technologies but reproduce like-for-like services. The tactical solutions that allow the business to move flexibly can be run by specialised in-house teams who are closer to developing business units and can permit the use of early technology adoption and rapid implementation. This way the costs and abilities are matched to the need for change, so the tactical vs strategic split sounds like a practical theory.

But in reality, how would you co-exist these two opposing models? There is obvious potential for moving tactical point solutions into the strategic mainstream over time, so service agreements would have to be supple enough to support this. There is a risk that tactical solutions might need transforming before they can be transitioned out into the supplier’s support model, so the in-house teams would need to adopt stricter standards early enough avoid cost barriers when they want to outsource a stabilised system.

The greatest challenge is likely to be choosing how to carve up technology layers that could be common to both camps. For instance, you probably want to have only one network, so you would consider this strategic. However tactical solutions might need certain components of the network to flex and adapt as they tried to make funky new solutions work across the company. But could you realistically say that the backbones and switches are managed by a vendor yet the firewalls are managed in-house? How would the supplier manage to SLAs when there are dependencies on in-house teams for core components of the layer they are trying to manage.

This is not to say that its impossible to carve up responsibilities between the two camps – simply that it will take a lot more skill and forethought to structure relationships that allow harmonious co-existence rather than leaving process gaps that can fill with excuses or blame.

]]> http://stationstreetsprings.wordpress.com/2008/11/29/will-rightsourcing-allow-you-to-balance-strategic-service-with-tactical-delivery/feed/ 0 Arthur M. Gallagher http://stationstreetsprings.wordpress.com/2008/11/08/a-simple-road-to-success/ http://stationstreetsprings.wordpress.com/2008/11/08/a-simple-road-to-success/#comments Sat, 08 Nov 2008 15:55:05 +0000 Arthur M. Gallagher http://stationstreetsprings.wordpress.com/?p=32 ]]>

Have you ever heard of something, and thought it was a good idea?

Great! The good news is that you’re already on your way to achieving it. The bad news is that 9 out of 10 times simply agreeing that it’s a good idea is not enough.

Ok, so why not make the clear decision that you are going to aim for this goal? Much better – but still, you’ll fail three times out of four.

Do you want to know what can bring you success a full 19 times out of 20?

Just increase your commitment by including another person and a review…

Research from The American Society of Training and Development shows that certain conditions improve the chances of completing a goal, and you can see them progress as you work through the following list

10% if you hear an idea.
25% if you consciously decide to adopt it.
40% if you decide when you will do it.
50% if you plan how you will do it.
65% if you commit to someone else you will do it.
95% if you have a specific accountability appointment with the person to whom you committed.

Although ASTD research suggests you will make it 2 out of 3 times if you make a promise to someone, you need to just go that one tiny step further and make an appointment expressly to review your promise and your achievement becomes almost inevitable.

Thanks to Kent Blumberg and Dave Opton for bringing to light this very illuminating  guidance on how to turn intent into outcome.

I apologise up front – despite trying to keep technical matters away from this blog, I felt this article was worth posting because it explains so clearly and abundantly a technology that you almost certainly carry in your pocket on a regular basis.

Most of us are familiar with cut-open images showing the spinning platters in hard disks that store our data at home and in our data centres. Every time we put on a film in our living room, we feel at home with the notion of little optical knobbles that reflect blinding laser light and are often used to back up our personal data.

But, when you snap your friends at the party with your digital camera, or listen to music on your phone, how much do you actually understand the vast differences in the way that those tiny plastic flash memory cards work, and how much they will begin to encroach on other types of storage?

I was prompted to find out more about flash storage technology because I was working out whether it was going to be better to buy more DVD-ROMs or portable hard drives for a certain purpose, when I realised that cost for tiny, light-weight SD (and microSD) storage was actually starting to get seriously competitive. Considering you can now pick up 8Gb SDs (almost twice as much as a DVD) for just over a tenner, and 32Gb cards are becoming common, think how amazing the progress has been compared with staid and bulky hard drives, or cheap but small DVDs. Ok, so 15 years on Blu-ray offers 25 & 50Gb capacity per disk, but its still not getting bigger and cheaper at the rate of Moore’s Law.

So whether you really want to know about the silicon and the electrons inside your Memory Stick, or you want to understand why your Compact Flash seems slow some days, and blindingly fast other days, or you simply want to understand the commercial realities of why Solid State Disks are going to give hard disks a run for their money, I can thoroughly recommend the clear and concise yet comprehensive (though perhaps somewhat bullish) article on Icrontic covering The hows and whys of SSDs. Enjoy!

You don’t need to understand the technology but its good to know why its here and where its going.

For many of us, making decisions is an important part of our job.

Sometimes you can make the decisions in isolation, but on other occasions it seems important to consider the views and opinions of other valued colleagues. Often the nature of the circumstances are so complex that it can be difficult to gather all the relevant information ready to make the right decision. And waiting for these people or this information can delay the point when you are in a position to make the actual decision.

But, after all, it is important to make the right decision…

…or is it?

Not according to Percy Barnevik’s “7-3 formula”! The man who ran Swiss engineering giant ABB for a decade insists that you can still be successful if you make nearly half as many wrong decisions as you make right decisions!

Speed vs. accuracy

The main reason why Barnevik advocates you aim for only 70% accuracy is to avoid wasting time. The days or weeks you while away, honing your decision until it is a shiny example of perfection, steal valuable time from executing the outcome of the decision. And given the speed at which the modern world revolves, delay can be tantamount to failure. If you’re lucky you might find yourself in second place on the podium, or worse you could be knocked of the medal roster altogether.

You might try to defend this resource drain, and delays to peoples starting activities, by saying it’s counter-productive to march too far in the wrong direction. But in reality much of the post-decision progress could apply to several different choices. Plan B might actually be able to use some of the work that Plan A generated, and it will actually be a head start because you got cracking on with Plan A as soon as you were allowed.

Best of all worlds

There are some principals that you can apply to increase your chances of benefiting from early decisions, even if they do turn out to have been mildly inaccurate:

• Publish the outcome immediately

The sooner everyone knows what you’ve decided, the sooner they can start to act upon it. Whether this activity abides by the decision, or stimulates a challenge to the decision, the main goal is to avoid wasting everyone’s time with uncertainty

• Trace what took the decision into account

If you make a simple note of every time an activity or deliverable considers a given decision, it makes it so much easier to reverse the decision. You have a list of exactly what you need to alter if you change your mind. Also, because you can measure the impact of changing your mind, this can be another factor that can help your next iteration of the decision.

Decision chains

There can actually be a chain of knock-on effects from your decision – your decision is a kind of mini design process weighing up input factors and producing “your choice” as the output. This can then be the input to someone else’s downstream decision, and so the chain continues. As long as everyone make’s their choices public, and refers to any other choices they took into account, everyone can trace the impact of their decisions and it becomes far more acceptable for people to change their minds, and as everyone still retains as much of the progress as possible.

Making dubious decisions work

There are other fringe benefits of placing less importance on getting the outcome of the decision perfect. Dispassioned decision-making avoids emotional bias  – this reduces the risk of following a bad decision with another just to avoid loosing face.

However people need to learn to judge decisions considering the information available, the timescales and the momentum from swift choices. There may be a merit in comparing outcomes, if it helps to improve the facts available for future decisions, but it people are scored on how many they got “right” then it might encourage dithering.

At the end of the day, even if the scenario of the question is stuffed full of facts, making decisions based on intuition is not as silly as it might first sound.

Planning a project is a opportunity to look forward to what we expect to deliver, working out the list of activities that move us from where we are to where we want to be, and marking the major stages of achievement along the way.

Think for a moment about a very simple model of what we are working towards. In order to implement process A, we need delivery framework B to connect system C to information source D, then we provide training E to customers F. Doesn’t that sum it up in a nutshell?

But hang on, how come we are even doing this in the first place? What was it that justified our very existence as a project? Well, chances are that someone pitched a business case to some executive sponsors and showed how a short term investment would bring long term benefits, either by increasing revenues, or as so often with major operations by reducing costs.

So that gives the even simpler model where we need to spend X in order to remove cost-base Y before we can realise benefit Z.

So surely these fundamental commercial events deserve a clear mention in our plans? Yes, I know that day to day we add value with rich information, precise actions and deep relationships, but at the end of the day business is about income and outgoings, and broadening the gap between the two. After all, the beating heart of every modern organisation is an organ that allows money to flow in and pumps it out again.

So let’s for a moment consider the larger commercial aspects of what we are doing. We know that implementing certain parts of our project depend upon spending money with suppliers. We also know that we cannot realise the benefit until we have put certain predecessors into place, or more often until we can tear down the costly old systems once we are sure our shiny new systems have successfully made them redundant.

I’m not saying that the commercially sensitive details such as dollar values should be publicly displayed in the plan, however the milestone dates really should. Any decision that affects these dates, and therefore the delivery of benefits and hence the business case that caused us to be here in the first place, should consider its true, wider impact. And if all the decisions are not in place to raise purchase orders at the appropriate time then how can you expect the rest of your supply chain to deliver whatever you were hoping for.

Seeing the clear list of dependant activities that stand between us and our project’s true business goal (+£ > -£), is the only way that everyone contributing to our project can stay objectively and pragmatically focussed on the big picture we are really trying to achieve. And considering the number of parties involved in many of today’s projects, we cannot be realistic about the time that will pass until we have properly planned the cash that must flow to make it happen.

I think that these twin truths make a very clear case for making red letter days out of our monetary milestones. Can you see yours standing out clearly in your plan?

When you’re planning a project or designing products, you know that you don’t need to produce any early mockups because you, and possibly many of the team, can see the vision already. You don’t need to see anything tangible before it’s due because you believe in what it is going to look like, way before you can hold it in your hands. Seeing as you’ve got so much ground to cover before then, its not worth delivering a symbolic item so early.

However, not everyone shares this same vision so clearly, and there can be so many advantages to producing and making available early beta and even alpha versions because tangible articles, even if they’re a long way from the final embodiment of perfection, are sometimes the best way to avoid very common obstacles.

Here are four that spring to mind immediately…

1. Your customers may not be as experienced at projecting the vision within their own heads, and it may be difficult for them to answer your questions honestly when you are trying to probe for requirements. Once you give them a toy to play with, they can very rapidly tell you what’s wrong with it and what they like about it. The more well-defined the “future reality” you present them with, the more well-defined they will express their actual requirements (rather than mere preconceptions).
2. There are a lot of people involved in a project, and if any single person sees a slightly different view of the vision, they may tend to go off on false tangents. Within the project team this is usually a minor issue, because control is strict enough to avoid inadvertant diversions. However, because projects rarely deliver in isolation, but deliver to other parts of the business, or often concurrently with other projects, it could be easy for other stakeholders to see the future differently. Unless, that is, you can give them a clear example of what you will deliver.
3. Even if there are pre-requisites to the final deliverables and logistical hurdles to mass-producing them as production-ready articles, you ARE going to have to produce them at some time. As long as the effort of hacking together a mock-up does not delay other areas unduly, its unlikely to be wasted time. Of course you have to be progmatic about which parts are realistic, and you should quality control the tests that other people run so that the final version also meets all their criteria. Some people might say “but we don’t want some non-technical business manager sticking their oar in and asking if we can produce it in the corporate shade of blue”, but they will say that whenever they first see it, and its better to get those questions out in the open way before pilot.
4. Sometimes it can be hard to deliver anything, so getting into the swing of it with prototypes is a great way of ironing out all sorts of wrinkles in the host organisation without letting them every get close to a critical path. Also, its unrealistic for a project to pretend that the business “as usual” around them will live suspended in a homeostatic bubble of rigidity. Change happens, and if the people delivering more change cannot keep in step with the changing world around them during the project, then they are going to have severe difficulty delivering anything at the end that the customer feels was worthy of the effort.

Sometime is might be clear that there is direct value to planning in early releases for people to look at. Even when there is not, however, bear in mind that encouraging people to lay their hands on alpha and beta versions of _their_ key receivables can be a mitigating tactic for so many potential risks that lurk around your project waiting for the opportunity to spring

I am finding that decisions form an increasingly important part of my role, so I was intrigued by this ComputerWorld article about reasons for decisions failing to deliver – Why decisions don’t stick

• did somebody make a decision?
• it was just a discussion!
• it doesn’t apply to me!
• it didn’t make any sense!

So did it seem that making the decision was difficult? The lesson here from CW is that communicating the decision can be even harder, but is certainly vital to your success. You need to make sure that you tell people you made it, that it sticks, that it needs to be adhered to, and most importantly why, so that people can internalise it themselves.

If you don’t bother sharing it, definitively, assignably and clearly, then you may as well be still scratching your head going “ummm, ahhh …”

I was happy to read a Rich Maltzman post on the “lifecycle of assumptions” (Scope crêpe: The biology of assumptions). Its reassuring to see that others place similar importance in tracking such potential bumps in the road, and realise that they can morph from one from into another.

I began some work a few months back into defining what I called Technical Governance. The classic entities used in project governance are known as “RAID”,  for Risks, Assumptions, Issues and Decisions. Two of the simple lifecycle stages I identified were that

• Issue =  circumstance that requires an Action that is not yet in the plan
• Risk = Issue that has not yet matured (or might not at all)
• Assumption = unvalidated fact that potentially leads to a risk

Although this was becoming promising, my focus was pulled away before I could complete the circle with with some earlier work on Requirements. Working on technological projects requirements are not just an important tool, they are fundamental. In the past I have had to widen the consideration of what constitutes a Requirement:

• Goal – top level requirement that guides choices in downlevel requirements and design
• Benefit – implication that a requirement will deliver a service improvement or cost reduction
• Standard – requirement implied by someone who is not a direct stakeholder
• Constraint – negative requirement (“must not” or “won’t”)
• Dependency – an outgoing requirement, where something is needed from someone else
• Assumption – made in lieu of a requirement

Here you can see Assumptions in another guise, where they are stated for clarity and audit traceability – better to have an assumption stated in the workings rather than hidden in someone’s head, where it can become really dangerous. Remember that with all of these entities it is important that all stakeholders can see them if they are interested – awareness is the first step to resolution.

I note that Rich describes an Assumption maturing into into a Risk as either as a Threat that something will get worse or as an Opportunity that things will improve. I’ll have to make sure I carry forward this idea that Risks can be positive as well as negative, because it is always so common to focus only on the potential for disaster – not what you need when your trying to make serious progress.

Another link between RAID and requirements is a Decision – if its a choice
made during design, it may lead to fresh constraints and dependencies.

As you can see there are plenty of ways in which you can get value from observing and understanding the behaviour of these various entities, to watch their lifecycles and the way they interact. I believe that Ethology can help Technology, but I have yet to convince my project manager that a day at the zoo will help us meet our milestones.