How to plan huge software projects?

Question

We've started a huge project. We know what it has to look like but not how to implement it. We started by writing prototypes to test different implementations. What we're lacking is the overview of the overall development progress. We don't know if we spend too much time on details or if those details are important enough to spend the time on.

I've started by creating a list of tasks we have to do, things like "implement feature X", "check how to implement Y". Now I have a huge mind map with about 500 tasks. The next step I could do is to define dependencies between the tasks. This way I'd know what to implement first and the tasks which are most depended on are the most critical ones. But I can't do this kind of ordering with the mind map tool. It's very frustrating.

How do you plan huge software projects?

Answer 1

Do your work in iterations. Concentrate on what is essential for one particular iteration. if you will be focusing on all details at the same time, you will fail.

Firstly, decide on what general functions you'd like to have and design for that.

On the next steps you will be adding more and more of advanced features.

When you have a architecture wireframe that is stable, you then can divide the project in modules and distribute them to several teams. Teams also will be working in iterations.

Nobody can design a huge software project from start. Huge project are growing slowly, with all usual childhood problems.

Answer 2

There are a number of good articles and books on this subject. But in brief, cut down dependencies, keep things simple but flexible, and start by writing quickly-codable components - this gives you a much better "feel" for how you will need to do things. Prepare for your designs to evolve and prepare to rewrite quite a bit of code.

Don't try to write the perfect system from scratch. Set out to write a simplistic system and you might, by accident, eventually end up writing the perfect system.

Answer 3

One bite at a time.

Seriously, looking at the whole thing is good as long as you don't get completely focused. We have to break it down into smaller and smaller projects until we can get our arms around it.

If you haven't already gone this way, any of the Agile methodologies work best. Scrum is great, XP is good. These use iterations, which is getting little bits of functionalitiy out as quickly as possible.

Trying to get your arms around the whole thing is really, really hard and I've found it extremely demotivating. But with an Agile technique, the users see progress immediately and our team gets excited because their code is being used in real life.

Answer 4

All this should come from the project requirements document, this will let you know which features are actually requirements and which features got added in scope creep. Make sure you implement what they want.

My advice always talk to the person you need to deliver the project to, come up with a schedule of when you will have important feature x completed by. Finding out what has to be done is a start via a requirements document and for large project (and small) priorities set on which task should be delivered first.

Talk talk talk is the best way to make sure everyone knows what is going on at all times.

Answer 5

Start with 1 peice, develop it, perfect it, and learn from it. Once you have done this, move onto the next piece. As you do each piece, add to your library of re-usable code. As you go, the process should get more refined, and development time should lessen. The worst thing you can do is do develop the whole thing in a waterfall based approach. Get something working and perfect it, this will not only allow you to show the bosses working pieces, but also allow you to find your natural balance between planning and coding.

If you want a formal way to plan, I would recommend agile development. It will give you a good guideline for how to plan your tasks and execute them. But I still think that a development team will fall into a rythm that suites it best and an incremental approach will allow this.

Answer 6

Obviously you want to break it down in smaller pieces, remember when doing the WBS (Work Breakdown Structure) to not only break it down to smaller pieces, but to also:

• define which pieces will be worked on first (prioritize the most business important ones)
• plan on delivery, many projects deliver code but then have a difficult time in promoting, plan how each release will be delivered and potential impacts to users
• get something done early/quickly - nothing builds confidence like an early win
• develop your communication plan - who needs to know what and when - Ex: for each iterative release who needs to get notified to the change/impact
• determine if you will re-evaluate feedback during releases to determine if order of delivery or functionality is changed
• realize that the sooner you release to production the sooner you need to support it as well as continue with development

Answer 7

This is what helped me to get started:

[1] Start with a requirements document. Write from the customers point of view. Write everything down what the software should be able to do. Avoid giving solutions. Be explicit. If a functionality will receive input specify what exactly it can expect, how much it should expect and how it should act in error situations.

Don't forget to specify limits. Everything has a limit. If your solution is going to manage accounts how many should it be able to handle? 20 or 10 million?

Your requirements document should include functional requirements and not functional requirements. Not functional requirements are: performance, stability, resource usage, security and so on.

[2] When you're done specifying requirements give every requirement a importance score: must have, important, optional.

[3] Now write a document where you specify how every requirement will be implemented. Be careful with the detail. Don't go to deep. Go for the 20/80 rule. Specify 20% of the functionality in-depth which will affect 80% of the solution.

You will probably notice, that you cannot describe how every requirement will be implemented. It is ok to write "I don't have a clue how to implement this". But it is important that you write this down! The amount of "don't knows" will tell you how risky your project is.

[4] The next step is to make a task list. You will need to know what actually you have to do. For every requirement you will have a couple of tasks to perform.

One of those tasks is to find out how to implement the "don't know" requirements. Don't try to clarify every "don't know". Go for the must-have and the important ones. Clarifying some of the "don't knows" may even be a mini sub project.

[5] Once you have your tasks estimate the time you need to complete them. Don't be shy estimating. It is impossible to estimate accurately when you're at the beginning of the project. As the project moves on you will re-estimate the tasks and you estimates will get more accurate.

It was very helpful to me to make so called three point estimates. Estimate the time you will need if everything goes well. This is you optimistic time. Then estimate how long it will take if you encounter problems. This is your pessimistic time. Then estimate a realistic time. The span between optimistic and pessimistic time will tell you how uncertain you are about the implementation.

[6] Now you will have to bring the tasks in the order they will be implemented. Some of the tasks will have dependencies which your order will has to reflect. There is a very good tool to help you visualize this order: your office wall. Write your tasks on post-its and put them on the wall. Seriously. It worked for me very well.

[7] Now you're already in the middle of your project. The sum of your estimates will give you two release dates (the optimistic and the pessimistic). You can set mile stones. Update the estimates for your tasks periodically. The change of the calculated release date will tell you how you're performing.