in reply to
Starting a Large Project
A few points off the top:
- Scope the project - on paper
- Meet with the stakeholders, get them to sign off on the scope
- Develop a plan, include design time, coding time, QA time, implementation time. Add extra fat to your timeline, becuase you'll need it.
- Once you have the conceptual design on paper, meet with the stakeholders - get them to sign it off.
- From the Concept design go on to write a detail design, (I use UML because its just so damn easy to learn and is very visual which suits me well)
- Submit your detail design to peers get them to read over your proposal and make comments.
- From the detail design talk with the stakeholders and make them understand how your project will run at a detail level. You dont have to go over the whole lot, just enuff to give them confidence in you. Get them to sign it off.
- Develop a prototype. At this point you can start coding. Put your basic business rules into code. With the meat of your apps, you can write stubs such as "Update the inventory here.\n"
- Show the prototype to the stakeholders, make sure they understand how things are being done.
- Develop meat. Add all the core functionality.
- Present developed app to stakeholders. They've signed this off, so they'll want to see the finished product before production. Compare your app to the signed off concept design/detail design.
- QA before a production implementation. You should *always* send something for QA. They'll test your app against a detail design, and do a bunch of other things like 'break testing', UI testing (if there is one) etc etc..
- Regular meetings. you need to show you are willing to communicate the status of the project. Even if the meeting is short, you should always communicate.
There are of course lots of detail missing such as documenting your unit tests, usability testing, requirement gathering etc, however depending on the your definition of 'large' they may or may not be important.
You may have noticed lots of 'sign off' comments. this is important for a few reasons:
- It demonstrates you are communicating with your stakeholders, (builds/ maintains confidence in you)
- They are getting exactly what they want, and you have proof. If they want something added toward the end of othe project, it should become a part of 'Phase II'
- CYA, CYA, CYA :-)
In reality however, things never seem to go to plan. You may not be able to communicate with the stakeholders effectively, they may impose a 'vital' bit of functionality at the end, you may not have peers willing/available to comment on your design.
If you follow some basic guidelines, communicate with the stakeholders, be honest about the status, you should be cool. Remember doco, its the most boring part of a project, but one of the most important parts. When you leave your job, someone else will need to know how/what you've done.