Software Developer gathering requirements, Department Managers providing input and discouraging input from Users

Question

I am finding myself in an awkward position. I am a Developer and I have been assigned the Development work for a Project that will convert a paper workflow to an electronic workflow. The small business I work for (about 200 employees) is very big on "Lean Culture", encouraging input from workers at every level. I have heard mixed messages about whether input is actually gleaned below the Management level, so perhaps that is why this Project is feeling awkward.

Some background information: Currently, orders are sent to a certain Section of a Department on paper order forms. The Section Manager does sorting to determine priority, and assigns the orders to Operators in that section based on their qualifications, and any other details that need to be taken into consideration.

The new process will route orders to this Department Section using a new Web application instead of having the Section Manager physically sort the paper order forms and hand them to specific users to work on. The application will contain logic to determine priority, and users will be assigned work based on their qualifications. The assignment logic will be contained in the application, and qualifications can be modified by the Section Manager.

I am feeling apprehensive about this Project because in a way, I have been given the role of Project Manager in that I am in charge of gathering the requirements. My authority is limited, though. The Department Managers have provided most of the requirements, and told me whom to include in meetings. The Section Manager has been in on the meetings, but I feel like the Section Manager is usually shut down on any suggestions, with the Department Managers saying that they want to ensure that "the 95% of cases that are straightforward and predictable are handled by the application". I do not know where the 95% of cases being straightforward came from, and I do not know how they determine that the points the Section Manager brings up fall outside that "95%".

The Section Manager is the only user of the application who has been engaged. None of the operators have been engaged. Getting into detailed requirements, meetings have just been with Developers and the IT Department Lead (who does have a wide knowledge of processes, but probably not enough so for most of the requirements to be coming from the IT Department Lead). Follow-up and clarification meetings have been held with Department Leads and the Section Lead for the section of the Department this will impact.

I asked the IT Department Lead if I could shadow the Section Manager and Users to understand the current process better, and he is grudgingly allowing me, but wanted to make sure that I understood and passed on the understanding to the Section Manager that we were "just focused on the 95%". I get the feeling any input I get from the Section Manager and Users will be shot down, because the whole 95% thing seems very arbitrary.

I want this Project to be successful, and I do not want the users or the Section Manager to feel like they are being forced to use a new application that does not effectively meet their needs. How can I be most effective in convincing the Department Managers that needs indicated by the users are important enough to be included in the requirements? I also feel like I am at risk of disappointing and/or causing conflict between the Section Manager and Department Managers if I am unsuccessful in relaying the message from the IT Department Lead to the Section Manager that the shadowing is not a guarantee that the input I receive will fall into the "95% of straightforward cases" and make it into the Requirements.

Answer 1

Not only is collecting requirements from users a requirement in and of itself to minimize the risk of building a product that does not work, but you are also increasing your risk around change resistance. Resistance occurs secondary to a change itself, no matter whether the product works for them or not, but when the product does not work, you'll exacerbate the resistance and lose credibility for the fixes.

I suspect the lead is trying to minimize costs and delays that could occur when the users get engaged, a lot due to disagreements, infighting, politics, etc. But this comes down to a pay now or pay later kind of thing, and the pay later will 10x the amount.

The 95% thing is a red herring. You cannot measure it and has no real effect on how the users will accept the product. This kind of thinking is a huge risk for your success as "finish" is arbitrary.

My recommendation is to escalate the risks your intuition is telling you and, if you're able, stop the project until everyone can get on board with a proven method of application development.