Three municipal web systems accepted within the contract deadline
A web agency had a contract to update three large municipal web systems but was at risk of missing the deadline. I joined as a systems analyst to help bring the work through formal acceptance. In under six months, I investigated and documented the systems, specified the required features, worked with developers on implementation, and led every acceptance stage with the client.
- Client
- City of Saint Petersburg administration, a municipal government; I worked through its contracted web agency
- My role
- Systems analysis and some project-management responsibilities
- Timeline
- Under six months from investigating the systems to completing acceptance
- Scope
- Municipal website backend and two public-sector website builders under one contract
- Status
- Formal acceptance completed, contract fulfilled within the deadline
The agency risked missing the contract deadline for three municipal systems. There was no documentation, and even familiar operations depended on numerous rules and settings.
I investigated behavior through the interfaces and test environments, documented existing features, and specified changes. I defined tasks for developers, prepared documentation with technical writers, and led acceptance reviews with the client.
In under six months, I took the work from initial investigation through acceptance of the changes across all three systems. The client accepted the work at every stage, and the contract was completed within the deadline.
Three municipal systems, one deadline at risk
A web agency needed to rework a city administration website's backend and update two website-building systems used by public-sector organizations. All three systems were covered by one contract. The scope was substantial, and little time remained.
By the time I joined, the risk of missing the deadline was already significant. My primary role was systems analyst, but I also took on some project-management responsibilities. I needed to understand the existing systems, specify changes, and help the team get the work accepted within the time available.
Complex rules behind familiar interfaces
The systems had no documentation. Even seemingly simple actions depended on numerous rules. Publishing a news item, for example, involved many settings that controlled both publication and system behavior.
Without understanding these dependencies, a change could affect undocumented functionality. I started by exploring the interfaces and testing the systems in test environments: varying settings, observing results, and recording the rules I uncovered. This reconstructed behavior became the basis for specifying changes.
Documentation for development and acceptance
Documentation was a required deliverable under this public-sector contract, with strict requirements. From the start, I structured my findings so they could be used in the client documentation. I ultimately documented all existing functionality across the three systems.
This served two purposes. For developers, it described current behavior and helped identify the changes needed. For acceptance, it became the basis of the documentation package I prepared with the agency's technical writing team.
Defining tasks and working with developers
I specified new features based on the behavior I had investigated and defined implementation tasks for developers. As implementation revealed further details, we updated the documentation.
Formal acceptance and a completed contract
I personally led every acceptance stage with the city administration, presenting the work and explaining how it met the requirements. The full process took under six months: investigating and documenting the systems, specifying changes, working with developers on implementation, and completing acceptance.
The client accepted the work on all three systems, and the agency completed the contract within the deadline. The administration received a reworked website backend, two updated website builders, and documentation covering all system functionality, which had previously been missing. After the project's successful completion, I ended my engagement with the agency.
I describe my approach to fixed delivery deadlines in a separate article: what to do when a project is behind schedule.
- A contract deadline is at risk, and the team or contractor needs someone to define development tasks and organize acceptance.
- A large system needs changes, but there is no documentation and its behavior must be reconstructed through the interface.
- The client, such as a public-sector organization or large corporation, has strict requirements for both system functionality and documentation.
Facing a similar challenge?
Send a description, requirements and any supporting materials you have. If you have none yet, a few sentences are enough. I will review them myself, suggest an approach and explain where to start.
Let's discuss your project