2013 theme park ....

Just before January is out I thought I would do my annual appraisal - just to make sure the 'revival' is on track!

2013 has been a roller coaster year for me on a number of fronts - but just how is the revival going. Well 2013 has been a bit of a milestone on the revival path. I've realised I am not as far off-piste as I thought I was when I started reviving myself. In fact, some bits don't need reviving at all they are revived and operating quite well thank you very much. However, not the bits you normally associate with software engineering!

The one thing that the past year has brought home to me is the pace of change in the industry. Frantic! Managing a business critical project in this constantly changing environment has been an exciting challenge in 2013. It just so happened that I started off the year studying for a 'certificate in complexity' at the Santa Fe Institute. Just out of curiosity, interest, development, not quite sure which. I didn't quite realise how useful this was going to be in understanding some of the issues that went throughout the rest of the year. Its a fantastic course (and book), I have said it before but say it again, thoroughly recommended. Plus its offered free, or was this past year, it was so good though that I donated to the cause anyway!

So complexity, in all its guises, is cropping up everywhere from social networks through to 'big data' and was the No. 1 theme for 2013.

The revival had started off as a wish to get back into some form of programming again. I did have a foray into Fortran a couple of years ago which basically told me not much has changed. This past year though this trail has led to specification and assessment of big-systems architectures. What started of ass an analysis of a requirements set ended up as a full on programme of work to install an asset management system for a large corporate. So a bit of a detour from the original but its a journey that I am very glad I took as it has given me an insight into both process and capabilities at this corporate system level. Something that I would normally have avoided like the plague being a more 'signal processing' guy! Although I didn't have much to offer in the big-systems front, or 'solution architect' front as it is called, I found I did on the process and management side of things. Specifically requirements and 'selection' processes and the management and engagement of teams. If you can codify what it is you are doing then you are half way to being able to explain it and indeed get others engaged in what you are doing.

So, codifying complexity in a process, a necessity to be able to focus development efforts and the team, is the No. 2 theme for 2013.

During this project there were two points throughout the year where there was opportunities to 'get on and do something'. Elements of the system could have been designed and built by the internal business software teams. That is rather than paying someone external to do it of course! However, the governance processes in the business essentially delayed activities to a point where it was then no longer viable to build internally anymore. Don't ask how this happened, safe to say that everyone was pushing for it to happen but the 'engine' couldn't turn fast enough. Which is a real shame, not to mention a costly impact on the business. The not-so-hilarious thing is that the external (big)company who was then employed to do the work suffered exactly the same issue! Blind leading the blind comes to mind. Its endemic - governance processes don't seem to have kept up with either the business environment or the agile working nature needed to service this modern climate.

So agility, not just in software development but also in decision making is the No. 3 theme for 2013.

A final thought relates to systems management - there are 'architects' at all points of the compass with conflicting advice - all very well though through of course. The trick however, is to know what the art of the possible is, and this requires clear business led management. Not IT, not any 'architecture' and not any expert system! It's engaging brain and putting in effort to understand exactly what the business needs and can handle in terms of change. 

So, taking back technical management control of complex projects, not project management or cost management is the No. 4 theme for 2013.

Here's to 2014 then!

Good to go

When is good enough - good enough?

When its Just Barely Good Enough, of course!

JBGE - I find - is the term used on agile projects to make sure you don't 'guild the lily' (GTL). Once you have something that can reasonably be built and tested the plan is to go for it in a 'sprint' development to get early sight and feedback on what you are building. Helps developers, helps users, helps produce a more targeted end product. You may have to go round the loop a few times refining and changing - but that's the nature of the beast anyway in the software development arena.

An excellent view of how this fits into agile developments can be found on the following link

www.agilemodeling.com

The issue comes when you try and introduce these techniques into organisations who are steeped in the more tradition waterfall approach to software development. Lets get the requirements - all of them - can't be doing with a bit of uncertainty, therein lies risk - write them all down then tick them all off as we grind through the design and development cycle. Trouble with this approach is - and don't get me wrong it does have its uses in certain arenas where you need to have full control and visibility - in a fast moving business environment, you will be overtaken by the opposition if you are not fleet of foot. If you are not careful the waterfall will simply be a cliff edge!

What the more agile approach provides are mechanisms for accelerating a project other than simply chucking bodies at it. You can shorten the 'sprint' - build intermediate releases, for example - which can help accelerate testing and user acceptance. You can re-evaluate what is JBGE for the development - does it really need to be all shiny and new?

Of course you need to make sure that what is produced is fit for purpose and doesn't fall into the NJCP category (Not Just Crap Programming).

Onward and upward ;)

Picture on the box

I have recently been party to issues around problems where a word has meant one thing to one person and another thing to another person. Both then plow on doing what they each believe the 'word' was an instruction only to discover at a later stage they were working to slightly different scopes of work. Resulting in a bit of a gap in what was expected. Which has started me thinking, is there a better way?

A picture is worth a thousand words, as the saying goes.

You think - yep I agree with that - and move on. However, can you actually communicate serious concepts across a range if individuals simple using pictures? What a great idea, no more reports, more importantly no more reports to format - what font size was that again!

Taking a project as an example, what would you need to do?

1 you would certainly need an organisation chart - that's OK that's a picture - tick.
2 you would need a project plan - high level, summary can be produced in a bullet milestone format for management, the workers can make do with a Gantt chart - they are pictures- tick.
3 you then need to convey what you actually want doing on the project - tough one this one - but then again how many meeting have you been to where when the going gets tough someone gets up and draws a picture? you could capture these somehow and 'Scoop' them - OK you would need a bit of commentary - but essentially a storybook format could be produced - picture based - tick.
4 you would also need to have a way of identifying all the various touch-points on the project - all those interfaces with the project that need managing - probably best done through a diagram anyway - tick.
5 you also need to manage risks - OK may need a spreadsheet at the back - but a heat-map type diagram is the norm - picture - tick.
6 how will the project management office function - process diagrams - pictures - tick.

you get the idea - for us dyslexics this is Nirvana - plus I believe it would go a long way to accelerating communication across a project team.

Prince 3 anyone?

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.....