Planning is good <ul><li>No matter whether your project is R&D, D or pure R, if you intend to produce software, some kind ...
Find the right level <ul><li>Development plans should be as detailed as you need </li></ul><ul><ul><li>but even simple pla...
Keep it useful <ul><li>Plans should be  useful  to the project manager/team leader/poor-RA-in-charge-of-everything </li></...
A simple roadmap <ul><li>Set regular, but arbitrary, milestones </li></ul><ul><ul><li>three months, six months, 12 months ...
Product-based planning <ul><li>PRINCE2 advocates product-based planning </li></ul><ul><ul><li>don’t think “what do we need...
And don’t forget… <ul><li>Planning for </li></ul><ul><ul><li>test: writing test code, running tests, assimilating results ...
Upcoming SlideShare
Loading in …5
×

Planning your project

293 views

Published on

Draft introduction to planning a software development project.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
293
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Planning your project

  1. 1. Planning is good <ul><li>No matter whether your project is R&D, D or pure R, if you intend to produce software, some kind of plan is essential </li></ul><ul><li>“No release schedule… no releases” </li></ul><ul><ul><li>anonymous professor, e-Science Core Programme </li></ul></ul>
  2. 2. Find the right level <ul><li>Development plans should be as detailed as you need </li></ul><ul><ul><li>but even simple plans can be very effective </li></ul></ul><ul><li>Plans with too much detail can over-constrain R&D, and can’t accommodate change easily </li></ul><ul><ul><li>“in six months time our software will have all the features detailed in this 48-page functional specification” </li></ul></ul><ul><ul><ul><li>no, it almost certainly will not </li></ul></ul></ul><ul><ul><ul><li>and you’ll feel bad about that </li></ul></ul></ul>
  3. 3. Keep it useful <ul><li>Plans should be useful to the project manager/team leader/poor-RA-in-charge-of-everything </li></ul><ul><ul><li>if you find Gantt charts useful, draw one; if you don’t, do something else that captures what you need </li></ul></ul><ul><li>Project management techniques provide useful tools to allow project managers to make better decisions </li></ul><ul><ul><li>there are lots of tools </li></ul></ul><ul><ul><li>people are different </li></ul></ul><ul><ul><li>find what works best for you </li></ul></ul>
  4. 4. A simple roadmap <ul><li>Set regular, but arbitrary, milestones </li></ul><ul><ul><li>three months, six months, 12 months </li></ul></ul><ul><li>Aim to release “something” at each </li></ul><ul><ul><li>but don’t tie the scope down too early </li></ul></ul><ul><ul><li>otherwise you’ll rush out something broken </li></ul></ul><ul><li>Pause development 3-6 weeks before a release </li></ul><ul><ul><li>review what’s working, what’s looking good </li></ul></ul><ul><ul><li>that’s the scope of your release </li></ul></ul>
  5. 5. Product-based planning <ul><li>PRINCE2 advocates product-based planning </li></ul><ul><ul><li>don’t think “what do we need to do”… </li></ul></ul><ul><ul><li>but “what do we need to make ” </li></ul></ul><ul><li>Especially useful for software </li></ul><ul><ul><li>think about what you’re trying to build </li></ul></ul><ul><ul><li>break it down into components… </li></ul></ul><ul><ul><li>break them down… and down… </li></ul></ul><ul><ul><li>until you get to things you can estimate sensibly </li></ul></ul>
  6. 6. And don’t forget… <ul><li>Planning for </li></ul><ul><ul><li>test: writing test code, running tests, assimilating results </li></ul></ul><ul><ul><li>integration: things don’t just come together magically </li></ul></ul><ul><ul><li>documentation: design notes, user docs, research papers </li></ul></ul><ul><ul><li>release packaging: installers, release notes, change logs </li></ul></ul><ul><li>None of this stuff is free! </li></ul><ul><li>Again, a product-based approach can help </li></ul><ul><ul><li>a research paper is a product too! </li></ul></ul>

×