Ever since transformation and change were linked to technology some of the worst parts of both have been combined on a national level and within major companies.

Giving users less functionality than they currently have and telling them it’s a great leap forward.

It is astonishing but this is the most common failing in projects, for some reason senior stakeholders appear to be convinced that technology is good and experience is bad. And if they concentrate on a new end state, all that is bad will go away. In a sad way all that is experience and knowledge are the things that go away often taking competitive advantage with them.

Asking stakeholders how things work even thought they only ever watch the outcomes and have no idea how things really work now.

Stakeholders by their very name determine that they are involved in the politics of a project, but they are considerably distanced from how thing work as they tend to represent management. This is less about the structure of projects in companies than how consultancies fail to ask questions about the current state, transition and opportunities into a project from a workers perspective and for service users.

Changing the requirements without understanding the long term debilitating impact of these changes.

There is without fail a point in all projects where the requirements will need to be changed due to cost, time or other constraint. At this critical point uniformly the future impact is relegated either to a later phase or someone else’s problem. While this at first sight is simply avoidance the impact in change, transformation and technology is significant often turning the current solution from strategic into nothing more than another tactical change that will need to be replaced.

Conducting due diligence on the project as a whole instead of across every aspect of the project at each stage and to the same consistent standard.

This may seem just a simple process but it is so often badly applied or not applied at all. There is naturally excitement when a project is in full flight but this some might say boring exercise often defines success or failure and will absolutely manage cost overruns which are often hidden by changing the requirements.

Not properly estimating and often severely underestimating the time it takes to create, refine, model, build and test solutions.

The reason that estimates are not correct is that translating requirements is not included in project planning. Project requirements must be translated into technical business requirements and user requirement both of which require testing and validation at a concept level before a solution can be considered to reliable, this is why so many project fail to deliver.

A brief note on requirements: Wish lists that make up an end state are not requirements these are just goals, requirements are what you get when you translate them into each delivery channel. For example the requirements to offer services to clients are different in mobile, desktop, telephony, marketing, pr etc. and they do not translate in the detail required to deliver. This is a highly common experience that no amount of lean and agile methodologies can make up or user experience cover up for the fact that most requirements given to technology as the bases of solutions are not fit for purpose.

Author Links;

Blog: user experience architecture
LinkedIn: profile
Twitter: userexperienceu