The key to a successful system implementation is to have solid business requirements. However in reality this is hard to come by, besides the fact that we too often think that requirements are sufficient to pass on to an implementation team.
As I wrote in an earlier post in my blog, business analysis is an ambiguous term. It covers two different but strongly related and even overlapping disciplines. The first is to analyse the business, its practices and objects to come to a model of the business and improvements of the business. The second is to analyse the need for a system and to model the required system.
This post is particularly about businesses where the maturity of IT governance within the organization is not mature; where there is a divide between the business and IT or where the IT organization or even the business in general does not have a high maturity level. Mid-sized and smaller organisations have additional challenges. They will not have elaborate project management offices or business analysis teams.
The perception is that when you do an IT project, you create business requirements and give these to the implementation team. And that’s where the problem lies. If you would look at one of the better known methodologies such as IBM’s Rational Unified Process (RUP), it says that you should (could) start with business modeling, then to perform the requirements analysis and then do a design phase. The problem is that business modeling and potential business change modeling is quite often skipped and that the design phase is insufficiently performed.
The key issue for smaller and mid-sized organisations is that the concept of business (process) modeling and business process improvement is too often not something that the relevant managers and business staff see the need for. They think they know how they operate and also know what the target process will be. Could very well be the case, but in my experience too often they missed critical aspects. Even if you explain the concepts and benefits of business process modelling as a starting point, they might not relate to the concepts. Managers are often the more experienced experts in their fields and seldom have a Masters in Business Administration. They much prefer to start building straight away and skip any requirements or design phase to save time and money.
The fact that there are many IT services firms out there that are willing to take on projects based upon a flimsy set of requirements does not help either. Why does the internal IT department want to overcomplicate things while you can get the job done quickly and cheaply outside?
Any qualified business analysts understands the concepts of business modelling. However when it comes down to bringing business change, either on a more strategic level or just on some practical processes, you need someone with sufficient experience in what it means to run a business. In the end you are dealing with people’s jobs. Not only that, but also quickly have a fair idea what processes potentially can be supported through automated systems. Someone just coming from Uni simply can’t do this. As a business consultant you need to be able to come into a settled organisation and explain how they can do things differently. The business team needs to trust the business consultant. Therefore it is best that the business owns this part of the project. In most organizations that relationship is insufficiently there with the IT department. In the end business process redesign is not an IT responsibility.
Skipping the business modeling phase brings the risk that you develop for the past or simply develop the wrong system. The business requirements then become too much a shopping list. If you’re not careful it becomes a passive activity and the business analysts has no means to value the individual requirements on their merits. The project might deliver what the business asked for but not what the business needed. If the requirements are collected over a larger group of users, you run the risk to get a rather incoherent wish list; something you better pass on to Santa.
Take an example outside IT. For example a sales rep can have the requirement: “I need a Porsche to visit my clients”. And he’s got a business case: “If I spend less time traveling then I can increase revenue.” Now you can go out and buy the Porsche for him. But business process analysis could identify that there are speed limits and that just a faster car does not help.
However the sales rep does not come with the issue just like that. There is something else hidden behind the requirement. Additional business process analysis could show that the sales rep uses his own car to visit clients and the company gives him a fixed rebate on the driven kilometers. To get the most out of his money, he adapts his route depending on petrol prices at the gas stations. This means he spends more time traveling than necessary.
A solution can be found by changing the financial construction. For example changing the business process by paying him for the actual costs spent. Or still give him a company car but just not a Porsche.
So once you know what the business needs and you understand the target business environment in which the system should operate, the system requirements can be detailed and subsequently you can work on the design of the system. And here we hit another painful element. Designing the system requires two primary things.
Firstly, you need to have a good idea how the users of the system work and how they would work with the system. For example, if they use a certain feature once a year you might implement something like a wizard and guide the user through the process. But if they would need to enter a large amount of data 50 times per day, then you would try to reduce the number of steps and place as much as possible input fields on a single form.
Secondly, you need to know what technical options there are. What are the existing components of systems? How would you normally model user interaction in a classical windows environment, how would you do that with a HTML based system and what are the options with more modern technologies? What will the user experience be and how does that support the users needs?
We hit the border between the applications architect and the business analyst. I see a weakness in the process where we just let the business analyst do the use cases and have the architect do the user interface design. The problem is that you already need to have built up a mental picture of the target system when you model the use cases. If you, as a business analyst, do not have sufficient experience in designing applications, you will not be able to make the optimal use cases. The architect on the other hand, usually does not have had the intensive exposure to the end users and their needs and will also not be able to come to an optimal design.
I managed projects where the architect and the business analyst teamed up and worked intensively together with the business users on requirements and design of the system. This can lead to very good results. That luxury does not always exist for many reasons. You might want to hand over the architecture and build work to an external party. Or the architect is still heavily involved in another project. Or the business users simply do not have the time.
Specifically in smaller projects you easily fall in the trap of oversimplifying the approach. “We all know what needs to be created, so lets write down the requirements and start building. Save time and money.” As a manager I always find this temptation very difficult to deal with. You see the value of the solution. You also see that if you want to take the right approach, the solution becomes more expensive and will be canned. For those smaller projects it usually will go reasonably well as long as you can stay focused, have qualified and experienced people and do not get any disturbances in the project. But if there are too many disturbances or you have less experienced people, the end result is usually not what you had hoped for. You pay the costs later through additional enhancements and a higher level of support.
My ideal business analyst has some years experience as a developer and as applications architect, is up to scratch with modern technology options, has quite some years experience as a business analyst and has good experience dealing with senior management in relation to decisions of how to organise and structure an organization. Unfortunately this limits the number of candidates in the marketplace.
Since the whole issue of business analysis does not only apply to custom development but also for implementation of off-the-shelf solutions and even for infrastructure systems, we just need lots of them. In the past the normal career would be from programmer to designer to analyst to project manager. Those days are over and people pursue careers much more within the same discipline. Maybe from developer to architect but the cross over to business analyst does not seem to happen too often anymore. Business analysts come straight from university and need to build up the required experience.
What I see is that we have foremost an industry problem. The best answer that I see for those cases where you are not in the position to run the project according to the book, is to bring the architect (or the lead developer) into the picture as early as possible and let him work closely with the business analyst during the early stages. Where possible let them both work as closely as possible with the business users. Use an iterative approach of development and test intermediate results with business users and business analyst as soon and as frequently as possible. This gives the architect and the developers early feedback on design and usability. (I am not promoting agile development here; neither do I say not to use it.)
And then there is the last nasty little problem with business process models, requirements and design documentation that I’d like to bring forward. Not always does the relevant business staff read the documentation thoroughly or do they really comprehend what is meant with it. Even if they will sign off on it. It is very difficult to go to someone and say: “You signed off on this documentation, but I don’t think you took the time to really read through it and I don’t think you understand what we are going to build for you”.
The answer to all problems is to have IT management properly embedded in the business responsibility. When you don’t have that luxury (and I guess that is in the majority of organizations), the best option is make sure your analysts and architects have the understanding of what the business needs. Not just what they have asked for.
One way to resolve the problem that I can recommend is through Service Delivery Managers. They stand with one foot in the business and with another foot in IT. They take care of day to day support to the business and manage small projects. With their in-depth knowledge of the business they are in a good position to vet the requirements and design on their merits. They have a fair idea of what the business needs, not just what they want.
Project management can help as well. A project manager might be able to force active participation from the business and therefore come to better results. It is the mechanism to control the inevitable scope changes and deal with issues of budget and time overrun. Horribly enough, project management is also the final protection mechanism against any blame for failure.
Never give up to challenge the business on their requirements and to understand the business processes. Try to identify the target business model and what the benefit of the new system would be in that context. The industry problem that we have is still too much that IT is not seen as an integral part of the business and that IT and project management are not embedded in the normal business processes. As long is this is not the case, it is our job to take the business by the hand and guide them on their journey through IT-world.
Business requirements too often stand on their own; not backed up by thorough business process analysis, insufficiently scrutinised and thrown over the wall to an implementation team. But if used as part of an integral analysis and design process, they are a key to success.
