Five most #common #failures of business #change and #transformation projects

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

Tagged : / / / / / / / / / / /

Save 35% ££ on banking change, requirements gathering should take no more than six months

Best practice, puting the missing part in a puzzle
Best practice, puting the missing part in a puzzle

Requirements gathering in Banking change programs are over detailed, over long and for the most part undeliverable.

There is and has been a huge requirement for change in British banking for several years as senior bankers have sought to lever the capabilities of technology and distributed workforces. This has in turn a great opportunity for IT consultancies to enforce their business models on the banks and make huge amounts of money without delivering anything. This has of course not gone unnoticed and forced many banks to increase their internal IT teams, but the problem remains, as the overall strategy is wrong.

The current strategy for business change requirements gathering is to fully understand the current problem with the assistance of subject matter experts (SME’s) and then defined the end state with the internal client. There are several major problems with this approach;

  • Fully understanding the problem is almost endless in Banking
  • Using SME assumes they really are experts which for the most part they are not
  • That the internal client can see the future of their business
  • That the same consultants will carry the project all the way through

The solution to this problem is a new strategy, in fact an Agile based one;

  • Defining 6 to 10 features of the new system at a high level
  • Involving the enterprise architects to see what has to be new, legacy or adapted
  • Launch the development team during the definition phase
  • Detail the features and get time costs from the designers and developers (not the PM or delivery manager)

Doing the above will change the relationship between requirements and delivery making requirements a service to the delivery of the project rather than an impossible set of promises made by people who will never have to keep them.

The 35% savings is probably low it’s just the 14 months and 35% of a budget wasted on an investment banking project that were eventually discarded. I’m considering a new concept in banking requirements gathering, value for money, is anyone interested?

You can contact me on karl@karl-smith.com

Tagged : / / / / / / / / / / / / / /