Software Projects with loose requirements

Question

What is the best method(s) to keep software projects on track when the requirements are loosely defined? (i.e. Just general functional concepts provided).

Answer 1

If the requirements are loosely defined then there should be regular and frequent delivery of working software to the client. Wireframes and prototype may help but not that much as compared to functional system. By working software I dont mean that build everything but initially focus on those pieces that will provide most value to the client. Let the client play with what you have built for them. This will also clear up the requirements for the client itself and they will know more about what they need instead of what they want.

Answer 2

First, you must be sure to get a handle on the project. A project loosely defined is loosely delivered, so change the starting state ASAP by:

1. Make sure you know the stakeholders and people who will be benefiting by the project. Get them to be clear about what they want, or how they will be obtaining value from the project.
2. Build an architecture/design sketch to get buy in from stakeholders and the development team. Don't leave it fuzzy, use the solution view to drive discussion about impacts of certain decisions.
3. Set a preliminary budget -and- timeline. You can change them later, but use these to start saying "with these constraints, we will have to start restricting scope" and use that to drive discussions about what is most important.

To keep things on track as you progress, get in the habit of saying "we are looking to call this feature/component done this release (before the next status report) and are looking for final feedback/comments" It really helps to adopt a periodic release schedule where the product is "potentially releasable" at the end of each release period (e.g. Scrum)

Keep the project divided into "things we know and can commit to develop by a certain date" and "things we don't know well enough to scope other than by the number of releases we should budget to complete it" That way you will always have one project you can control/monitor and report on. Keep enough work in the well defined portion of the project to keep the team buffered while you and maybe a tech lead work to bring definition to the other portion.

Answer 3

I'd work out what "on track" means, first. Is there a minimum feature which needs to be delivered by a certain date? A business outcome which needs to be achieved? If so, this should help to provide a focus and vision for the project. If there's something small which can be delivered early, this is a great way to prove the team's ability to deliver, gain the trust of the stakeholders and buy time for later.

Once the vision's been established, work out which aspects of it are least well known. Are there parts of the UI which nobody can envisage properly? Architecture which has never been tried? Hard-code the rest, and get feedback on these risky aspects as quickly as possible. Aziz's suggestions of regular showcasing is the best way I've found to do this. Remember that different areas of the project will have different stakeholders, so for instance, showcase any architectural learning to the architects; UIs to the users; business functionality to the departments which care about it.

Rather than focusing on value, I tend to prefer focus on risk (remembering that areas of poor or limited knowledge tend to carry a bunch of risk you don't even know about yet), and then deliver the smallest valuable thing that will make a difference. This can be done repeatedly and incrementally until a larger vision is achieved.

Answer 4

In terms of a methodology, Steve McConnell's Rapid Development provides a table that shows which methodologies are appropriate for projects given certain project-level characteristics. For projects with "poorly understood requirements", spiral, evolutionary prototyping, and the use of COTS software are rated the best among. Modified waterfalls and evolutionary delivery also appear to be suitable, but not as much. If you notice, these are methodologies that provide high visibility for both the customer and management into the work being done by the development team, allow for "course corrections" in the middle of the project, and are designed to assist in the management of risks.

However, there are a number of criteria that McConnell uses to choose a methodology. This includes an understanding of the requirements and architecture, the desired reliability, risk management, the use of a pre-defined schedule, amount of overhead, customer visibility, and so on.

If you have a copy of Rapid Development available, the table that I'm referencing is on pages 156-157. You would probably be interested in most (if not all) of Chapter 7, which discusses Lifecycle Planning. Chapter 6, which discusses McConnell's take on Rapid Development, might also be of interest.

If you are going to be managing software projects, I would highly recommend not only this book, but also McConnell's Software Project Survival Guide. Both books were (and still are) required reading in the software process and project management course that I took, and are highly rated when it comes to SE process books. They also focus on "best practices" that apply to a good number of projects.

Answer 5

A requirements are loosely defined project is a recipe for trouble.

Your job as PM should be to tighten the requirements.

• Define milestones
• Define what will be delivered by each milestone

The next milestone or 2 (or 3) must be concrete; the future ones can be more loosely defined, until they move up the pipeline, then the have to be clearly defined.

It's not possible to create something that is loosely defined. Define it and track it.

Answer 6

I still believe that's not realistic to have a good tracking in a loosely defined project.

Although I believe the other answers provide the best way to turn around the problem, I'd still make clear with the stakeholders that we can't have clear deadlines without clear project milestones. It would make them share the blame for any delays that (eventually) will happen.