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.

  • 1
    Aside from requirements, are they giving you example cases? You can ask for these on the grounds that you need them in order to test. If it were me, I'd ask for at least 10 example cases, 8 "straightforward" ones and 2 "non-straightforward" ones. The resulting conversation might elicit more clarity (esp if they can't come up with 8 straightforward examples...) Sep 27, 2017 at 20:46
  • Have you asked the managers how your system is supposed to identify the "5%" cases that it shouldn't handle? You should at the very least have requirements how to identify those cases and spit them out for manual processing. Sep 29, 2017 at 9:51
  • Thanks, those are good suggestions. I will ask those questions in the next meeting with the business side. There doesn't appear to be any process for requirements gathering (this was just put on a task board for me as a development task; I suggested it should have its own board of tasks rather than being a task on the board, but response was "That would be a waste of time.")
    – Poosh
    Oct 5, 2017 at 17:41

1 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.

  • Most of what I've worked on here so far is bug fixes. I'm familiar enough with the system to start working on larger projects. I was surprised to find that this "task" on the development board assigned to me had no requirements yet. There doesn't seem to be any standard for gathering requirements. I completely agree that the investment in gathering requirements pays off. I suspect suggesting a proven method of application development, or at least for gathering requirements, will be met with a lot of resistance, and I don't think I have the power/reputation to put the project on hold.
    – Poosh
    Oct 5, 2017 at 18:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.