Okay IT pros, change happens. But here's your Reg guide to staying in control

When I started my IT career, the organisations I worked with didn't really do formal change management. And that wasn't really a problem: either they were small enough for it not to matter (we just told the handful of users: “We're about to upgrade X”), or the departments I worked in were sufficiently small and autonomous that …

[Halfmad]

That's all great but..

when I worked in IT in the NHS we'd have to carry out major changes during core working hours, when it was damn near certain that something would go wrong, despite us consistently asking to do the work either in overtime at the weekend or at the weekend and claiming the time back (no cost to the NHS..) it was always refused, it always had to be done during "lunch" which seemed to be any time between midday and 3PM.

Invariable things didn't work or had to be rushed. So whilst I agree with everything that's being written, if you can do the work at a quiet period, then do so.

[Daggerchild]

Re: That's all great but..

Heh - I see the opposite problem : changes that 'must' be done out of hours that should be done in hours.

Tweak a complicated thing at midnight that causes ripples. Nobody sees any problems (or they see problems that could be instantly fixed by someone who went home hours ago).

Workers then come in in the morning and find some things have been subtly broken for several hours that they would have noticed instantly in hours reducing the damage.

[Anonymous Coward]

Re: That's all great but..

I can assure you that in NHS land it is still very much the same. IT and the service desk only operate 8am to 5.30pm Monday to Friday, even though we have a *lot* of community patient contacts out of hours or at the weekend, and then there's the over 1,000 inpatients.

Occasionally you get permission for an out of hours change, but that can still involve taking down the medical record system for three hours because there is no budget for having a DR system you can just switch between.

Change control can also be a real pain with certain systems that you don't have control over.

We still have the remnants of the NPfIT system hosted by CSC over a dodgy Citrix connection - so no real control there at all, it's all up to CSC, who tend to do what they want when they want and have a god awful escalation procedure (seriously, to put a ticket in for "everything's down" involves an excel spreadsheet that takes at least 20 minutes to fill out it requires so much tosh).

Then there are the systems that you can host yourself, but as part of the contract with the supplier, they demand standing remote access to the system, without notifying you in advance (looking at you, Emis). In theory, before major changes (like deploying an upgrade or hotfix) they should schedule it, but have a tendency to email the wrong person, and no one in IT. Cue everything keeling over when their hotfix doesn't play well with the OS and the clinical lead ringing up asking why it's died.

Proper change control goes out of the window when you have patients backing up in clinic over multiple sites who cannot be seen.

:-/

[Unep Eurobats]

Scope creep

Tell me about it...

The most insidious way this happens is when the client's idea of what they've asked for gradually changes without them realising it. Because we're all supposed to be agile now the requirements can be as vague as they like. They don't know what they want, all they know is that whatever we deliver isn't it.

[Steve Davies 3]

Re: Scope creep

Is why every Government IT project ---

1) Goes over budget

2) Is late

3) never delivers what it originally intended

It is also how the likes of EDS, Crapita, PWC etc make their money.

Obvious innit

[allthecoolshortnamesweretaken]

Re: Scope creep

Not just government IT projects, and for that matter, not just IT projects...

It usually helps if the first step is you helping the client to figure out what they actually want. They think they do, but in most cases they are wrong.

In my experience, a 'you are ordering a new car, what do you want to do with it and what features should it have' analogy works pretty good. Or the 'you are booking a holiday trip' analogy. These are concepts (nearly) everybody can grasp and has experienced already. Also, IME most people actually do spend more time, care and thought on buying cars and booking holidays than they spend on buying real estate, finding spouses, choosing doctors or lawyers, etc.

[JerseyDaveC]

Re: Scope creep

Completely agree. The business users generally don't actually know what they want. They have a good idea of what they *think* they want, but that's what analysts are for - to dig the actual requirements kicking and screaming out of the users and to write them down comprehensively and unambiguously. This is way from trivial, and takes significant time, but is well worth the effort.

And that's what I meant when I wrote about "it will be what they [the customer] asked for". Done properly, the requirements will be sufficiently black and white (and will bear the customer's signature) that even if they say: "That's not what I wanted" you can categorically say: "But that's what we both agreed would be delivered".

[Robert Moore]

Re: Scope creep

I used to work with a PM who had a brilliant way of dealing with scope creep.

Client calls up and says, "We think it would be great if the software would do SOMETHINGSTUPID."

PM says, "Fantastic idea. Since it isn't in the original spec it will only cost $X to implement. Would you like me to send a revised quote?"

$X = several tens of thousands of dollars minimum.

Worked nearly every time. When it didn't work we got more billable hours. :)

[Aristotles slow and dimwitted horse]

@ Scope creep...

Possibly. But I agree with the sentiment of the article in that it's not necessarily scope creep that causes projects or programmes to fail, but the lack of an adequately scaled or robust programme framework with the rigorous functional governance in place to manage and control it.

"The most insidious way this happens is when the client's idea of what they've asked for gradually changes without them realising it. Because we're all supposed to be agile now the requirements can be as vague as they like"

But this isn't "Agile". It sounds as though your organisation (like many) don't understand the method. You reap what you sow though right...

[Bill M]

Or join the 21st century.....

Or join the 21st century and simply adopt an Agile Software Development methodology and all the pitfalls of Waterfall Software Development and then all the issues Dave Cartwright is whinging about are irrelevant.

Or remain a dinosaur and as Aristotles slow and dimwitted horse say you can "reap what you sow"

[Steve Davies 3]

Re: Or join the 21st century.....

Agile?

Fragile more like.

It is not the panacea that people like to make out. It can work for some things but for others? Forget it.

more like 'Close to the Edge' than 'The Yes Album'.

[Bill M]

Re: Or join the 21st century.....

Glad I don't won't work with people who stick to dinosaur approaches.

I am successfully managing an agile multinational BI project that started with no spec apart from the Board wanting to know "what the hell is happening in the business". The Board and users love what has and continues to be delivered, None of the previous attempts with Waterfall Project Management delivered anything that was adopted let alone loved.

Agile Project Management can be an unsettling concept to those who have not yet enjoyed the successes it delivers. But Boards love that it delivers solutions and not problems. And I am glad to say they reward me with copious beer vouchers.

[Anonymous Coward]

Re: Or join the 21st century.....

So, in your spare time are you playing the role of 'Superman'?

different bits of IT development run at different speeds.

Having completed all the DB, SAP and middleware Dev needed by the end of sprint 1, we still had to attend those silly standups every day for the next 5 sprints by which time the Java devs doing the front end actually had something for us to test with.

Agile my arse.

[Anonymous Coward]

Re: Or join the 21st century.....

Agile is awesome....I come up with vague ideas and push them out to people who do 18 hours shifts to clear up the shit I've created.

Get with it.

[Bill M]

Re: Or join the 21st century.....

Stand Ups are part of Scrum and not Agile Project Management per se. It is a common misconception to confuse Scrum and Agile. As Agile is agile one caters for different speeds and avoids silly Stand Ups, and only have good Stand Ups with the correct people when a specific dev phase will benefit.

My full time role is 'Superman' as the Global IT Director once mentioned in a covering letter re some bonus beer vouchers he was bunging me.

In my spare time I redeem the beer vouchers as per their intended usage.

[Doctor Syntax]

Re: Or join the 21st century.....

"avoids silly Stand Ups, and only have good Stand Ups "

The "no true Scotsman" approach.

[Dan Wilkie]

Re: Or join the 21st century.....

See the last time I had to interact with a BI team was when the 10 year old seagate HDD which they had removed from a decommissioned desktop machine so they could have their own "server" and not have to go through IT's processes failed. I put in a lot of time file carving to get their databases back (because there were no backups - presumably that was too dinosaury as well), and then two weeks later half of them stopped working. Which obviously was my fault.

The databases were Microsoft Access databases. They were 2GB.

But that's my fault.

If they'd gone through proper scoping at the beginning, then they wouldn't be faced with an issue 6 months down the line where their chosen database technology was incapable of supporting the data they had. Nope, they'd have ended up with an old fashioned SQL database that they couldn't have looked after themselves but which could handle the data being put in it.

I've been part of Agile projects before and I agree it can work out well. A lot of the time however it's seemed to just promote shortcuts and bodges, I guess I'm a dinosaur.

[Bill M]

Re: Or join the 21st century.....

Agreed: MS Access is a cheap fragile kiddy toy, my preferred RDBMS is Oracle - I spent a decade as a DBA.

Although BI with Data Warehouses / RDBMS's has passed its sell by date. In memory analytics have now come of age.

My condolences to you re the BI cowboys who wasted the time you should have been using to redeem beer vouchers.

And 'no backups' !!! I trust they were fired. The hotel industry has the 3 L's, Location, Location & Location. IT has the 3 B's, Backup, Backup & Backup.

[Gazareth]

Re: Or join the 21st century.....

If you spent 10 years as a DBA, you really should have learnt that it's not the backups that are important, it's the restores.

[Bill M]

Re: Or join the 21st century.....

Yup - You're are correct. Thanks for the correction on my semantics.

[Anonymous Coward]

Re: Agile Project Management can be an unsettling concept....

....to those who have not yet enjoyed the successes it delivers.

No, it's those who've been on so say "Agile" projects and seen the complete lack of results that find it unsettling.

I've no doubt that when done correctly it can work. I've yet to work somewhere where it's been done correctly.

[Doctor Syntax]

Re: Or join the 21st century.....

"what the hell is happening in the business"

This may be a very brief requirement but it's a actually quite a good one and one which suits an iterative process. To any given level of detail it has a deliverable and if more detail is required another iteration will produce another level. When the client says they've got enough or spent enough it can stop. A different requirement might not be so suited to that approach.

What's really problematical about it is that the board didn't know what the hell was happening in the business in the first place.

[Anonymous Coward]

Re: Or join the 21st century.....

Yeah, Agile in a medical record system, or a system that controls X-rays, or an e-prescribing system.

Whoops! The last patch seems to have meant that in some cases insulin doses are increased by 5 fold from what was prescribed. Good thing only one patient ended up in a coma before it was discovered!

[Destroy All Monsters]

Re: Or join the 21st century.....

Or join the 21st century and simply adopt an Agile Software Development methodology

Change management has scant to do with development, software or otherwise. Nor with Waterfall.

Think about this. Being unable to do calculations does not mean that you magically will have enough money at the end of the month.

I am successfully managing an agile multinational BI project that started with no spec apart from the Board wanting to know "what the hell is happening in the business".

HAHA right. You are either full of bullshit or it's the rest of the team that does that actual work and you are glomming on it.

Now step away from IT and keep your hands in the air, buster.

[JerseyDaveC]

Re: Or join the 21st century.....

Don't get me wrong. I'm not anti-Agile. I'm just anti-cowboy. Uncontrolled change breaks systems, no matter what methodology you're trying to use.

[Warm Braw]

Antidote to scope creep...

In a number of more bureaucratic organisations where I have inadvertently strayed, the staff have demanded training before even the slightest change to established procedure could be introduced. This could be an extremely effective limit on scope creep - and indeed on scope in general.

However, said training commonly revealed that neither the managers nor the front line staff even understood their existing systems - or their purpose - so the whole notion of "scope" was moot.

In that context, the whole Universal Credit debacle becomes more understandable...

[Anonymous Coward]

Scope

The problem is sometimes the scope contains:

- items that engineers and data scientists see are really critical to the whole project, without which it will fail

- items that are 'nice to have' for the operational staff - like a pleasant GUI (which changes with the GUI "du jour" ), without which it will be clunky, but can work

- items that are some PHB's pet hobby (which changes erratically)

- items that get imposed from on high during the course of the project, with no attention to the original scope, or even the purpose of the project.

The trouble is that the least attention goes to the first item.

[John 104]

Re: Scope

@AC

SCOPE

And that is the problem with DevOps.

[werdsmith]

My changes are often checked and approved by people who have not the slightest idea of the effects and consequences of the change.

Those same people are quick to distance themselves from any ill effect of those changes too.

[energystar]

'Profession' has a meaning, and a price for each of us to pay.

Paying that price, and then being fully open toward our Guild Union in first term, and toward Society later, is one of the paths forward, in this -very sad- present situation.

Shared responsibility. Is how England came out from Middle Age.

[fruitoftheloon]

@Steve Davies 3: Re: Scope creep

Steve,

A little while ago ~10 yrs I had an 'interesting' role with the Capita Risk team, a key part of which re big sales pitches necessitated:

- reading the ENTIRE client reqs document(s)

- reading the ENTIRE draft contract from the sales bods.

Often there would be lack of congruence between:

- what the client said they wanted

- what the sales bods and techies THOUGHT the client needed

- what the client actually NEEDED

- what it was technically and practically viable to deliver within the defined timeframe(s)

I am proud of my achievements therein, bearing in mind that human nature rightly points out what f'ed up, but overlooks what worked (yes there were several).

Trouble is, the type of role I had only worked if your boss reported to the Group FD, who incidentally made Gordon Ramsey look like the UN Secretary General...

Cheers,

Jay

[Commswonk]

Re: @Steve Davies 3: Scope creep

This posting reminded me of this: http://imgur.com/gallery/NXHbZ.

[Doctor Syntax]

I had one gig where the manager had a set of requirement's similar to Dave's to set up a new product. They included a requirement to specify up-front the SQL needed to make the changes to the database. The application, however, had been implemented with a user-friendly front-end form to make the changes to the various tables. This would include working out the surrogate keys on the live system which would be different to those on the development database. It simply wasn't designed to work through the import of raw SQL.

[energystar]

This advice is extreme PRO-SECURITY

And should be a REQUISITE when coding DEVELOPER TOOLS. 5 of 5 Stars :)

[John 104]

Ah, there it is at the end. DevOps. I knew it was hiding in there somewhere...

[energystar]

Digital World full of 'sandy' Burj Khalifas, Dave.

" started out with the intention of building a sandcastle and ended up with the Burj Khalifa"

[Agent_99]

I worked for a major Defense Contractor on Federal computer projects for 28 years.

My pet peeve was operational staff who tried to use Deficiency Complaints as a back-end method of scope creep.

Essentially, the staff member wanted a new feature that was not included in the official change requirements, neither at the system level or the software level.

These were staff members who did not have input into the official software change requirements, so they tried to make deficiency complaints that their needs were not being satisfied, because the new software did not deliver some nice individual feature that they personally considered to be a requirement.

Acceptance Review meetings were usually a piece of cake, except for the inevitable political fight where users refused to sign off the delivery because of their pet peeve, and the software group refused to deliver features that were not part of the formal Requirements.

[Anonymous Coward]

It doesn't matter what process you follow, it's whether you can stick to the process/plan/framework or whatever you might call it.

You can spend thousands on project management and change management, produce all the shiny plans, graphs and workflows you like. But if the person managing it can't find their own backside with both hands and an anatomically correct map, then it's going to fail.

The biggest problem I come across in change management, is lack of flexibility, and over abundance of process for no real gain.

In a lot of places now, I hear that to enact a change, a customer has to raise an invoice for a project review to take place, to see what is required and if it requires a project resource to be allocated to make the change.

The change could be "Open the firewall port to the server YOU built and YOU did not complete properly on the project we already paid you to do" but it still requires 3 months, multiple meetings and at least 3 additional costs, just to work out some guy forgot to type 12 words and click half a dozen buttons.

If you've got a fire in your server room, you don't want till Wednesday for your CAB to meet to decide if you should raise a financial purchase order for a project review to allocate a resource to push the halon release (because you're also the BOFH and of course you're still using Halon).

There needs to be a process to deal with some things retrospectively, as part of risk assessment and management, as not everything in life can be processed pro-actively.

[JerseyDaveC]

It's a fair comment - and you're right, there are change control processes that are so onerous as to make everyone want to avoid them.

At the very least all change control processes ought to have an "emergency" case that allows for rapid response (generally in cases where something's down or something's so poorly that service will soon be down if you don't act).

And one would hope that dealing with your PFY spontaneously combusting wouldn't require change control; though whether you tell him/her that at the time is down to whether they've made you tea that morning.

[Corinne]

In a number of previous lives, I've had to write and manage change control processes. The first thing I try to make the PHBs understand is that there really isn't a "one size fits all" option, you need different processes for "if this doesn't happen now, the live system is bust" to "we would quite like this expensive brand new functionality". Obviously in the first case you need to just have some form of sanity check then one responsible person sign it off, in the second case you need to go through full impact assessment (both positive & negative), costings, & consultation with various stakeholders.

At one organisation we ended up having 3 levels of change request process as we were working on a (broken) inherited system that needed immediate bug fixes to the live system, plus urgent functionality changes, and the replacement system being built from scratch.

I would tend to find the best cure for unnecessary scope creep would be the results of a proper impact assessment; "if you want this change it will cost you £mega, and put the whole thing back at least 6 months" can mean something that was absolutely critical suddenly becomes something they can easily do without.