Pip pip old chap.

How about this one then?

I think we should replace the PID with a PIP!

PID - Project Initiation Document
PIP - Project Initiation Period

Never heard of it - what does a PIP look like?

Well its a period of time that is dependent upon the size of the projects - could be days, could be weeks - which is set at the start of the project by the Steering Group but crucially it is not communicated to the project team. Its a period where the team are allowed to get to grips with the project. Verbal instructions are given to the team on what needs to be done on the project - key deliverables, timescales, that sort of thing. Selected individuals are put in charge of producing these deliverables and told to get on with it. This does assume the project team are highly skilled in the subject matter and have delivered on projects in the past. You wouldn't want to put a novice in charge of any of this. But then you wouldn't do that under the PID type arrangements either.

Chaos can then ensue for the period of the PIP. Who's doing this bit, where's that bit, there's a bit missing, nobody is accountable for the other bit. Regular daily meetings control the chaos somewhat. Eventually the situation settles down (hopefully within the PIP) with everyone aligned.

What this would do is remove the illusion that somehow the PID and its controlling board sessions allow you to systematically manage a complex, multi-interfacing project. You have let the complexity emerge in a natural way and allowed the team to get to grips with it in a manner that facilitates delivery.

What you haven't done is drive the project (yet) - which is the usual approach to project management, beat the thing into submission, cost, time, resources. However, what you have done is avoided driving it off the rails before its even got underway ;)

Et Voila ..... an agile PID .......

Mobilizing the immobile.

Big companies are tough to get moving at the best of times but when you need to sprint rather than jog the frustration is gasket blowing.

Bogged down in process and governance frameworks, in which you need a PhD in jobs-worthiness to understand, the whole setup feels sclerotic. There must be fast track approaches that can enable the vast resources in these companies to mobilise without the need to fill in forms and tick boxes?

Don't get me wrong I fully understand the need for governance on projects, but the type of governance needed relates to actually control over whats being done. Not the sort where the easiest decision - usually by people remote from the project who just don't know what its all about - is to say no. Big companies are full of layers of such checking. I just wonder at the value adding. I suppose it keeps people in a job?

Even when up and jogging these businesses seem to have difficulty getting everyone on the bus and working in the same direction. Enter the power of the PID (Project Initiation Document - see PRINCE). Big business like these types of document - ah at last, something to tell us what to do, who is in charge and when we need to do things! Not unreasonable, but if you know what you are doing on an agile type development, not really a great help in delivering the project or creating the momentum and focus needed to deliver to tight timescales.

But great for ensuring a few boxes ticked .....

Tunnelling through.....

To summarise;


A Roadmap is all well and good
But the end game is well understood

Short timescales, detours, you wont make it on time
What to do, well, follow this rhyme

Straight line, via a tunnel, through to the end
Is the only thing without a bend

Assurance is key to this tunnelling spree
To make sure you don't destabilise things

Beware this may become, a more permanent route
A highway to heaven or hell

Just check with the Roadmap, the end is what matters
Then close your eyes and dig, dig, dig

;)

Following the 'Roadmap'

OK so you produce the 'roadmap' for how to start to integrate the new systems into the old - could be cloud based, could be crowbar into the internal setup, could be complete new redesign of internal. All of which make for good roadmap's - people like this roadmapping - you can explain what you are up to with a roadmap. The interesting part is what you start up the engine and begin to drive using the 'roadmap'.

What you find is that it is difficult to run a programme/project just using a 'roadmap' - the signposts are there but the details of what awaits you on the roads is what is needed when you drive. Bends, hollows, potholes (just driven down a few of them), pedestrians, cyclists all sorts of hazards that can only be negotiated on-the-fly. No amount of project (re)planning will help you much either - though you will probably be able to frighten yourself with how much all this dodging is costing you.

Sounds like you need to be 'agile', particularly if you have a strict deadline looming, but what does agile mean? Can a large programme actually be agile? Haven't we been there before with Rapid Application Development (RAD), and other associated methods?

Or is it the other definition of RAD - Rapidly Approaching Disaster - that will be the norm?

The drive continues.....

The art of the impossible.....

cont' from Steep Curves post....

Not just solution architects but also ..... so far and counting;

• Enterprise architect
• Solution architect
• Data architect
• System architect
• Software architect

once upon a time all you had to do was write the code!

All these architects are in place to try and manage the complexity and poorly connected nature of all of the various applications and corporate systems that have grown up over the years without any thought for how they fit or flex within a changing business environment. Not to mention the disparate data sources, multiple systems, multiple variants of the multiple systems.

Or maybe it has all been through design? ..... I doubt it.

This landscape is changing rapidly though.

Do you bother even trying to engineer something into your current IT environment given the issues related to implementing new systems  into this complexity? With all the architects in place making sure you don't mess with the business, it can take an inordinate length of time to get anything up and running. That's before you hit any 'stuck bolts' in the new system built itself. There's always a thousand reasons not to bother.

Enter the Cloud. Vanilla environment, vanilla interfaces, vanilla support, vanilla politics, vanilla risk, vanilla .... I can now see the attraction.


What is needed is a 'roadmap' so we know where we are going and a driver to get the bus moving .....

Silent type

Not been very blog active over past few weeks.

Sensitive job and holidays got in the way of typing. Job now sorted so normal service will be resumed. 

It's been an interesting few weeks - have learned a tremendous amount. Think by brain is about to explode!

Just how do you get to grips with complicated IT, massive business change and distributed data of varying quality?

To be continued.....

Steep curves.

Learning curves that is!

Related to big data - in real companies with old legacy systems (COBOL - are you kidding me!), system variants (are you running V10 or V10.1?), a plethora of home grown (and I hasted not to call them) packages as well as multiple and complex processes for getting systems onto the company infrastructure (to make sure you don't muck up the current operations of course). Add to this time pressures of day-to-day business activity and the need to maintain existing system issues and upgrade in line with user expectations.

The very definition of complexity.

HELP - how do we get control over the big data - can we start again!

The answer of course is yes - but. How do you start to get a grip of this landscape?

Do you drive new business change projects into it to flesh out issues and interfaces, or take a global view of the mess and plan a grand strategy around what needs to be done. Or indeed do both simultaneously. Can you initiate 'agile' projects to get buy-in from stakeholders - indeed can you use agile in this type of environment?

Bring on the 'Solution Architects'.

We will see......