Getting your proposal approved is only the start. The picture you painted for the business owner and the operating departments is still a provisional picture of the future. It only becomes real once the chosen solution is delivered and actually meets the goals you set.
The complaints you hear in every project meeting
Reality rarely follows the plan. A project can run into problems at any point. As an IT manager doubling as project manager in a non-IT company, these are the complaints you hear from stakeholders:
- The vendor’s business analyst says: the business users are not confirming requirements on time, so development will slip.
- The business users say: the requirements are written vaguely and probably do not reflect what we actually need.
- The end users say, once they see the product: this is not what we thought we were getting.
- The vendor’s project manager says: the business keeps changing requirements, the schedule is no longer safe, and this will cost extra.
- Your own senior management says: at this pace, how does the project go live on plan? We need to escalate to the vendor’s leadership.
At that point there is a real risk your proposal does not deliver what you promised when you convinced the board to fund it, and your standing with both the board and the business starts carrying a question mark.
The root cause is requirement quality
There are a thousand possible causes behind those complaints. In my view “the requirements were too poor” is the source of most of them, and it is the thing few project managers are willing to admit at closure.
Five things that improve requirement quality
So how do you get good requirements? Here is what has worked for me.
1. Do not expect too much from the vendor’s business analyst. The requirements they gather are tied to the boxed product they already sell, and they pay much less attention to the real state of the problem in your company. Often they simply listen to the business describe something and write it down, and the language the business speaks and the language the analyst writes in are not the same language.
2. The business people are always busy. You have to do some lobbying, over meals outside the office if that is what it takes, and explain to them why their input matters to the project. Ask questions that draw out what actually bothers them: policies, processes, forms, approval and control mechanisms. That is how you get at the submerged part of the iceberg. Business people respond very well when you speak their professional language.
3. Spend time studying how leading companies in your industry, locally or regionally, do it. Their success was usually paid for with a lot of failed system builds. Learn their policies, their working processes, and their approach to building systems. Then filter for what you can realistically implement to upgrade your own business processes. This is the approach the smarter IT managers at foreign-invested companies take.
4. Set up a requirement management mechanism between you, the business users and the vendor’s analyst. Define what the business users must produce, what the vendor’s analyst must produce, and state the required quality bar up front. You are the owner of the project, and requirements are the biggest single source of project problems. Spend the time here at the start instead of managing defects caused by weak requirements later.
5. System integration is still a real challenge. When you upgrade or introduce a new system, you have to work out how it interacts with everything else in the company’s management information system. Internal politics often builds invisible walls between departments, and the software landscape ends up mirroring those walls. As the person responsible for the MIS, part of your job is removing those walls whenever you add a new component to it. The “automation first” approach a lot of IT managers now push is largely aimed at exactly this integration problem.
It is hard, but people do it
You might say all of this is too hard to actually do. IT managers at large foreign-invested companies are doing it. And your own boss expects you to step into that role and create bigger value for the business.
Get the toolkit: BABOK v3
It is hard mostly when you have not equipped yourself with a strong enough toolkit. The International Institute of Business Analysis has distilled practical experience from professional analysts at large organisations worldwide into the BABOK v3 guide. Read through it quickly and then practise it on a live project. You will improve the quality of your work and remove a lot of the sources of trouble in your projects.
More importantly, you get to prove that the solution you wrote into your business case delivers the value you claimed when you pitched it. Your boss’s trust grows on the back of project results, and you start getting bigger projects instead of being treated as technical support for someone else’s.
