Requirements and Project Efficiency

Project experience will tell you that almost every project starts with good, albeit ambitious intentions. They are created and then sent down the pipeline to the planners and eventually to the doers. There are several stages of the life of a project and depending on how each stage is handled can affect the final results going out on time vs being delayed and being accurate vs unintended UI/UX implementation. All of which can affect your relationship with the paying client or internal stakeholder.

Projects with longer completion times tend to fare better when it comes to planning as there is organic time built into the process. Projects with surprisingly abrupt start dates which need to be finished quickly can often be chaotic and shortchanged in the planning department, but that doesn't mean that they still can't go through the same phases as a longer project, its just that the team will need to act quicker and attempt to be as thorough as possible when they enter each phase.

Lets go through the project phases and see where time can be lost or at best maintained.

The Idea

Hopefully by the time the new project even gets to the project manager there is a clear idea of what needs to be created. We don't need to dwell on this too much as it may largely be out of our control but it is important to note that the project manager should be brought in as soon as possible. The PM at this point is an outside viewer with fresh eyes and that perspective may already be able to point out issues or inconsistencies in the plan from the outset. The PM should also be able to help with setting expectations for if the deadline is attainable, as he most likely has already many other projects in progress and will need to assess available staffing and bandwidth.

The Deadline is Set

As soon as a project starts there is typically a relatively deadline. So you already have a certain amount of time to complete it. A well run project can maintain its timeline at best while chaotic projects will certainly lose time. Rarely can time be gained without the original timeline being altered, this could happen due to pure luck such as outside contributors are late getting you essential pieces to help you progress forward. In most cases bad project management will disappoint the stakeholders and the deadline will begrudgingly get pushed out.

The First Meeting

The PM should have an initial meeting with the team leads who will be part of the project, which include developers and QA. It is essential to have QA involved at this point so they can already be thinking about their testing strategy. As well, they may also be able to offer improvements due to their unique perspective.

This meeting is where it needs to be clear who owns the requirements. This means who writes them and who is in charge of them. This helps with any questions that may arise during the development and testing phases. The team may decide to all be present when the requirements are entered into a wiki there should be a point of contact who is aware of everything needed.

One philosophy on generating the tickets for the work suggests that the requirement doc should be written as user stories. User stories are easily digested scenarios involving the end user experience. These should be clearly stated and then from there tickets should be generated for the work using almost verbatim language. This helps with traceability and limits confusion. The ticket should also have a Desired Behavior field and this should be used to say how the change in every ticket affects the end user, no matter how small it is. This greatly helps QA work more efficiently as they should have everything they need and do not need to take time to disrupt a developer or PM.

If the project crosses multiple teams then leads from all teams should be present and their corresponding project tickets should be written as closely as possible to the other teams tickets. This helps create UI and business rule parity among all the platforms/systems.

One additional exercise that can be fairly beneficial is doing a pre-mortem.  This is a strategy which involves the team coming up with worst case failure scenarios for the project.  This happens before any coding is done. You detail everything that can go wrong with every part of the project.  Performing this exercise can get your brain thinking about scenarios that may have gone under the radar and potentially forgotten about until later in the project. It can be a fun form of risk management and add some levity to particularly stressful projects.

Meeting with Stakeholders

The PM and development team will ultimately have a large say in what the final design will look like. Changes may need to be made for the final product to be more doable/faster/easier. There should be regular check-ins with the stakeholders to make sure the team is still on the right path. There could be potential implementations that are not liked by the client.

Change

A large part of the Agile process is flexibility. The ability to shift directions or change original ideas. Business needs change fast as the modern business world hurdles towards continuous delivery and with this, expectations and needs change almost equally as fast. The PM will need to keep up on documentation as he is fed the changes. Language in existing tickets in the backlog should be altered as well.

As the project moves along there will inevitably be the need to create new tickets on the fly. Some of these tickets will be written by developers as they are needed. It is important when these new tickets are prioritized and estimated that the language in the ticket is analyzed and simplified in case the title and description include “techie” terms that may be confusing to others. Again, the Desired Behavior field should be updated as well.

The PM will also need to know how these changes could potentially affect the final deadline. It's possible the stakeholder asked for major revisions and how the team can handle the injection of these requests will need to be articulated by the PM.

Contingencies When Things Get Chaotic.

There are some outside forces that can derail even the most well run project. These can take the forms of unexpected personnel outages, travel delays and other factors. However, even these can be slightly mitigated if contingency plans are set in place earlier in the project.

Time for UAT and Beta Testers

At this point most of the expected work should be done. And its possible that at some point along the way the stakeholders and implementation teams have decided that there is more work to be done but this will be phase one of the project and phase two will be implemented at another date. It is here when the stakeholders will see a “finished” product and will accept it or not. Around this time is when beta testers, if available, can also test the product. Expectations of future maintenance should be reviewed here as well because there may be issues found which will need to be addressed.

The Whole Picture

Projects will take all sort of shapes and sizes and seasoned project managers should be able to use past projects as a guide for how new projects could potentially go. Even with tight timelines it is important to front load as much planning as possible. Take that initial time to plan it out and involve as much needed personnel as available/needed as early as you can. Requirements that are well-defined and at minimum have a single owner will lead to clear tickets and easy development and testing, which in turn lead to the product going out on time. And that can make all the difference.