Turning an Unclear Request into a Clear Work Plan

The request sounded simple: move manual work into an internal web service. The goal was clear, but the scope was not.

The source had thirty tabs and links to other internal services. If we had started at once, the target would have kept changing.

What was the problem?

I first split the request into clear needs. These included data storage, manual input, links to other systems, login, and access by role.

The words “build one portal” hid many different questions. We had to know where the data came from, which work should stay, and who could use each feature.

How I compared the choices

We also had to decide who owned the work. One support group could help with the system and its operation. The team close to the request could build the product.

This choice was not only about sharing tasks. It also showed who would make later decisions and who would run the service.

What I chose and did

I checked the source material myself. Many of the thirty tabs were empty, copied, or old. Moving all of them would create work with little value.

After checking real use, I reduced the list to seven active areas. I also checked how three existing services and their test data were set up.

Then I split the release into steps. The first version would collect links to current services in one place. Deeper data links would come later. This gave users value sooner without hiding the work that still remained.

What happened and what remains

The real target changed from thirty named tabs to seven active areas. The team also agreed on the roles for system support and product work.

The first release will bring current access points together. Login, access rules, and deeper data links remain as later work.

What I will do next time

For an unclear request, I will check real use before writing a long plan. I will remove unused work, set clear ownership, and split early value from later work.

A quick first release is useful only when everyone can also see what comes next.