UX

dino

It seems almost impossible these days to read any articles talking about digital projects that aren’t bubbling over with low-cholesterol-smugness and holier-than-thou-high-protein goodness.

But let’s face it, out in the real world, 9 out of 10 digital projects will have a couple of bad weather warnings, the occasional spring shower, a small tropical storm perhaps. If you’re a smart cookie, you’ve done your due diligence and risk assessment sufficiently well that you probably have enough wet weather gear to cope without even getting more than damp

And number 10? Well, that’s the one they make the movie about, the tenth project will be the one that might kill off the dinosaurs. That’s the one I am going to chat about.

Today’s bedtime story concerns a project scenario I assumed intermediate control of several years ago and that, on paper at least, had all the hallmarks of success. All the project documentation had already been signed off, there appeared to be system technical documentation leaking out of the woodwork and we were already in production with an experienced team of front end and back end developers. With plenty of time and resources to hit deadline, everything was looking rosy.

Well, that was my initial opinion.

On my second day I started to actually read the documents in the library, and they were an absolute dream. Unfortunately, said dream was one of the nasty kind involving people called Freddy with blood and knives and screaming and such like. They say the devil is in the details, and in this case he meandered crazily between far too much information on irrelevancies, all the way up to abstract art on areas where detail would actually have been rather handy.

I appeared to have inherited completely vanilla versions of the project requirements and technical design documents. Other documents were glaringly absent, items such as DFD’s, ELH’s, technical infrastructure, integration, API definitions … Let’s just say the list of missing technical information was extensive. It was difficult to tell which was worse between back end and front end. Meanwhile, UX, still in its infancy back then, was simply absent, leaving only a smidgen of rather limp IA documents.

I didn’t really think it could get much worse until I started looking much more deeply under the hood at the back end operation. This is when I discovered that all of those wonderful technical documents mentioned earlier were instead living a rather bizarre virtual life inside the head of the primary technical lead. This guru, and he was brilliant, was unfortunately not that great in the planning and estimating department.

My first physical foray into this maelstrom was to question a few very basic, but crucial, usability issues I found in the project requirements document  – i.e. the main piece of work that was being used by our UI resources to build the front end. I was informed by the client partner that, whilst we might be able to squeeze the timeline at the end to incorporate some of these changes, it would have to be on the down low and I was to treat the existing documentation as written by Moses and help. Boat rocking was clearly a no-no.

Back then fixed budget waterfall methodologies were still the only option available for agency, projects were leaping from cliffs with no idea as to what reception they would receive at the bottom.

And then, in my first meeting with the client, I discovered the ultimate in coffin nailing. My specification, time and budget signed off project was still inb the process of evolving. I didn’t see the full agenda, and so I was quite surprised when the meeting, with myself, the PM, the clients and of all things a designer,  was mostly concerned with approval of interface designs.

To my terror, the clients, with no technical sense checks at all, were approving controls, forms and  processes presented by the designer who was making these changes without any UX or technical safety net. I think I may have had an aneurysm.

The situation didn’t improve when I was informed that the developers would just have to work off these new annotated designs. So, instead of a designer working off approved and signed off UI/UX wire frames and working to an approved style guide, she was instead redefining the whole project with unlimited client iterations. Madness.

The one positive aspect, or so I thought briefly, was that the client was very, very understanding about this continuous design amendments having a financial impact due to UI development – seemingly throwing piles of cash at us for simple design changes.

The only problem was that the piles of cash in question didn’t even come close to the total change management cost, being limited only to extra development time.

And so, with components being designed, modified or cloned willy-nilly. No account was given to the fact that the back end would have to be modified extensively to allow for these changes or that the HTML/ CSS/ JS would also have to be changed. That the project definition document would need to be amended to track the changes which also meant an updated test plan as well. Finally, the overall project plan and Gantt would have to amalgamate all of those changes. In other words, those 2 days quoted by the technical team to represent the updated designs actually represented about 20% of the true cost.

And that was the state of play 3 weeks into the project.

I don’t mind admitting it, I was in major trouble and I was fighting the urge to do a Lawrence Oates, feign enormous arctic al fresco peckishness, and just to go out for a really, really, long lunch one day.

First off, I did have a really long lunch, although I spent most of it disaster management planning. I knew the asteroid was coming, I knew its size, I just didn’t know yet how bad the impact was going to be and whether I could get any of us to safety first.

The very first item on my agenda was to stop any further design led changes from happening, and to do this I inserted myself in between the designer and the client as a technical safety net. Actually, less a net and more like a reinforced concrete wall with dogs below and razor wire on top. And mines, lots of mines. If at this point any further changes were really required, I made sure the cost reflected reality. And then I doubled it.

At the same time the UI and test team took a time out for 2 days to re-estimate all remaining work based on that snapshot in time, using the changed designs and updating the requirements document, which in itself had to be fed to the testing team for updates.

The most important step was to remove the fog and come up with a real plan for the back end. In this case we were in a situation with virtually no documentation but one very smart cookie who had lots of beer mat estimates. I took over a small meeting room and we sat down together for nearly a full week to go through my very big list of what I thought should have been in the original documents and why.

We talked, we argued, we laughed (briefly, but ironically), we drew diagrams with lots of arrows, we made more notes and, it must be said, I drank a lot every evening. Based on this work I then waited for our technical guru to come up with the numbers. A bit like an expectant father, all I could do was hover anxiously.

After the first week of detailed analysis I discovered the project would probably be 3 weeks over on the original estimate. I could handle this, it was well within the scope of the overspend if we sucked up our gut and used an extra in-house resource.

Another few days went by, more diagrams appeared as the evaluation continued. The delay then turned into 6 weeks. Then it was 10.

At this point I had to bring in the client partner and the directors and suggest that whilst we had a major disaster of a project that was going to be a minimum of 2.5 months late, it was more probable, in my humble opinion, that the delay would more likely turn out to be double that.

After the disbelief and acrimony, it was clear that the only solution was to man up, be as direct and honest with the client as possible; humble just short of reaching for sharp Japanese implements of death. We needed to try desperately to rebuild trust levels.

To cut the next three month into a very short story, we did deliver the solution, approximately 14 weeks later than originally planned. This involved bringing in 2 extra external resources and a lot of late nights and stress. That wonderful client trust, unfortunately, was never recovered.

Now, a lot of you out there will be clinging smugly to your new agile UCD process and exulting that this could never happen to you. I would counter by suggesting that a process is only as good as the people inside of it. The truth is that even if your process is watertight, it is still reliant upon the efforts of individuals, their skills and the inherent risks within your entire team.

If I was being slightly negative my advice might be to always embrace your paranoia, cherish your scepticism and trust no-one. However, if you think about what went wrong in the above tale, you should be able to see that every possible misstep could have been easily overcome by a combination of user centred design, proper planning, effective team communications and some good old fashioned honesty.