Is there a method to thy madness?
During the 25+ years that I have been in the business of trying to make what we see on the screen, what-ever the type of screen, both suitable to the purpose and easy to use, I have seen the rise and fall of a quite a few methodologies. In fact they are so many that I don’t even remember the names of more than a handful. What they all had, and have, in common is that they honestly aimed at solving the IT Project Paradox.
The IT Project Paradox is the fascinating theorem stating that any IT project, at any given time, might or might not deliver according to either budget, deadline, or specified qualities, regardless of effort and good will. Each new method that tried to solve the paradox is less of a silver bullet than a reaction to previous or prevalent methods. RUP tried to solve the problem of scope. Scrum tried to solve the problem of too much documentation. Lean aimed at weeding out inefficiency. The different methods that we as UX or Service Design practitioners use try to solve the problem of too little focus on the people or the business and context that should use or (and?) benefit from the new or redesigned solution.
Of course I am simplifying things here. Many of the methods aim at different parts of the process; the design aspect, the ability to measure success, the ability to build effectively, the user aspect, the business aspect, the project process, the product life-cycle…
But. Having worked with this plethora of methods, either because a client organisation mandated it, because it was the flavour of the year, or because, well, I honestly believed that this particular method would guarantee a timely delivery of something that the organisation would benefit from I am, 25 years later, only certain of one thing: all methods are corruptible.
If you don’t know why you are doing what you do, and if you are not brutally honest about it, no method in the world will save you.
Looking at the bottom line any project or any effort at continuous refinement will need to ensure four specific aspects, or no effort or model will save you. These are -
Never lose touch with the real reason for doing the project
The following are not reasons for a company to spend time and money on an IT solution -
- To make the salesperson rich
- To realise the personal dream of some CXO
- To spend money on hardware, licenses or consultants
- To make users happy
- To write beautiful code
The only reason for doing the project is to achieve a business goal. That goal is specific and has qualifiers and success criteria. Everything else is just means to an end. And some things aren't even means. They are just mean and selfish.
Lose sight of the real “why” and you will fail.
Political bravery
Earlier I mentioned honesty. This is probably the most difficult component. For every failed project there is a few people who knew beforehand that the effort was doomed. Why didn't anyone listen?
The particular reasons are many-faceted and complex. But at the heart is this — either the project has a sponsor, an owner, someone in charge, who actually understand the business reasons that underlies the project and who is fearless in regard to other stakeholders, including those who nominally rank above said person. Or it hasn't. The latter is the Face of Doom. The latter is more interested in boosting his CV, to build a career, than in the business objectives.
Facing those people, and facing people who expect you to deliver regardless, requires bravery.
Know your different stakeholders, intimately
No matter how you acquire the knowledge — the important thing is to have it. Thinking that you know isn't enough. You need to be able to empathize with each stakeholder, to think like them, despite them having opposite goals.
Such knowledge is not based on assumption. It is not gathered, documented and mapped by having the people who for example manage a certain type of team workshop about it. These people are a stakeholder group of their own and act as poor representatives for the actual user group.
Likewise real insight into different corporate cultures can only be taught to a certain degree. There’s nothing like hands on experience, and labels only act as shorthand.
Respect your team
An Art Director needn't know JQuery syntax. A front end developer needn't know how to analyse an a/b test. Really. It isn't a shortcoming. The world is complex and a team is stronger when each and everyone does what he or she is best at. The renaissance jack’o’all trades is a pipe dream. Yes, there exist the odd person who is extremely talented and experienced in one than more field. Those are not the norm. Most of us are really good at some few things, and reasonably good at some more things, and with a need to know-based familiarity with a mixed array of stuff.
In team sports you have specialists, each with his or her designated role. The mentality of a scorer is very different from that of a central defender. If you don’t make them respect each other, make them work for and with each other, the team will under-perform, relative the qualifications of each individual. The same applies to a project team. And. Respect is not bestowed. It is earned.
Get a project a project manager with an obsessive compulsion for keeping order
Seriously. I am not kidding. A compulsion for orderliness is paramount when running projects, especially fast and light ones. Because that is what it takes to make very different personality types and competences perform a complex coordinated multi-spatial ballet, in real time.
A certificate in project method A, B or C doesn't cut it. Experience implementing huge ERP systems doesn't cut it. Not by default. Not when we talk modern business oriented end user focused solutions. I have seen some epic fails from experienced project managers.
Bottom line
So, in conclusion, having these things — and there’s no “any two of the four” here: it is all or nothing — what method you actually chose; how you document your requirements and success criteria: those are more a matter of situational context than an objectively good or bad method.
What method is the best fit is more about corporate culture, type of organisation, and legal structures than about type of project, or because one method is inherently “better” than all the rest.
Ensure a sure sight on the actual business goals driving the project, get a fearless project manager who excels at creating a respectful working climate, know your stakeholders — and chose a method that suits your circumstances and context (and not what friend A or community Y recommends as “best ever”).
Suddenly your chance of success will sky-rocket. In my humble experience.
