Do alpha releases deliver value? Maybe more than you think!

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… Read the rest of this entry »


Making your mind up is only the start…

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 …”

Technical governance entities

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.

Look who’s been doing my market research for me!

As an independent professional working in Information Services in the UK, I prefer to specialise in blue chip organisations. I think you’ll agree that this places a nice firm definition on my target market. Well you can imagine how happy I was to find that CIO Magazine’s UK website publishes a rather neat list of the 100 most important companies in my market, and with a paragraph summary of each, the name of the head of IT, and a handy page describing many of the current key directions and challenges.

CIO 100 Gallery – Top 100 Companies In The UK For IT – CIO UK Magazine

Blow me down if that’s not just what I need, being handed to me on a plate, for free. 🙂 Ok, I know that others can see this, just as I can, and they may be competing with me (delivering similar services, or attempting to get in the same person’s diary), but have a look at some of what is there and you can see the potential power of this information.

Also, because CIO’s needs are import to my career potential, its really handy to get an understanding of what they see as their concerns – for example 70% of CIOs of global companies see Consolidation is a very important challenge (source: CIO Executive Council poll, May 2007)

Hats off to IDG’s CXO media for doing my market research for me – long may they continue…

A project blogger’s secret power comes from his impotence

I’ve heard discussions about why collaboration platforms and social media can help on projects, but some people are somewhat sceptical about blogging on projects. However, I would like to demonstrate how even on a busy project a blog can be a poweful means of communication.

I’m sure you’ve been there yourself, when your email inbox gets snowed under. When it turns into a mountain of issues lurking, waiting for the moment when a single loud bang can cause an avalanche of responsibility wars. How can any EXTRA incoming communication possibly be a good thing?

Well, think about the nature of items in your inbox. When the going gets tough, mails turn into gotchas-in-waiting, as they are easy to misread when you skim hundreds of messages a day. Some mails are magnets that make you inadvertantly pick up actions, others snare you into unwitting sign-off, and others tick silently like timebombs that will be trumpeted later as evidence of passive malpractice on your part.

In this tidal wave of potential traps, what could be more welcome than a new message which no-one will expect you to act upon, which you will not be berated for not fully digesting, which in fact its not at all in your jobspec to even bother opening. The mere fact that you “can safely ignore it”, makes it a more welcoming read. Not only will it not put more furrows in your brow, nor increase the statistical likelihood of any follicle producing you a grey hair – it may actually stimulate you to think about something refreshingly unpressing, in a positive and supportive way.

Reading blog articles is specifically anti-pressure, because you CHOOSE to do it. When everybody around you is crumbling under the oppressive regime of their mailboxes, what more powerful way have you to communicate than something which will be read and seriously considered, simply because people have the right to ignore it completely, if they want.

If you wait patiently enough the future will arrive

So is 2008 the year we’ve been waiting for? Well, according to Enterprise Management Associates (EMA), many of the hot topics this year has in store for us are exactly those I’ve been striving to achieve in various organisations over the past ten years.

IT Management Trends to Watch for in 2008 lists such fantastic, yet common sense items as:

  • data centre automation (DCA)
  • virtualisation
  • configuration management database (CMDB)
  • automated IT service management (ITSM)
  • governance and risk management

So my question is … “if IT infrastructure managers have been able to ignore the massive cost savings they could have accrued during the past few years by capitalising on these techniques, why are they going to suddenly turn around in 2008, see the light, and start doing it all?”

Perhaps EMA’s various research tracks for 2008 will help shed light on golden opportunities for us all

Thanks to Uttam at Locuz for pointing out the press release

Complex designs come unstuck on the simple things

I used to think that the most difficult part of creating a complex infrastructure design was fretting over the important technical choices that would affect the configuration of deliverables. Once those were sorted then I could get on with listing the order in which elements needed to be implemented, and producing a list of all the technological resources needed to implement them.

Over time I’ve come to realise that this is actually the wrong way round. Often design choices are the easiest stage, partly because many infrastructure components work best when following vendors’ best-practice configuration guidelines (or even just set up as they come out of the box). Also, because most configuration is soft, its easy to make such choices at the last minute and still deliver it right and on time. The more important elements to get right up front, however, are those that require the time and the money, also known as dependencies and resources.

Read the rest of this entry »