WestCoast2008:PM Principles - Software and Database Development

Notetaker: Mark

What people want to talk about

1. How to choose tools
2. Documentation and QA
3. Managing people, especially not full time
4. Managing times
5. Managing software projects rather than websites
6. Research on things that have worked
7. How to plug in volunteers
8. Bill versus buy questions
9. Scope and scale

Gunner's intro

Generalizations
1. Prevalent pathology is the old school laboratory model. avoiding the whole spec, then developers go and hide for months and hand over a fished project to the client
2. Connect with peoples' pain and passion
3. To avoid, Agile development is encouraged, partnership with passion, work with people during the difficult parts to encourage a painless final outcome
4. Present things of value to clients as quick as possible, get them politically engaged right away. if clients get value right away, and appreciates it, and gives feedback, the stakeholders will be happy
5. All successful tech projects work on the same model of the community organizing model
6. Do these apply to internal projects? the answer seems to be yes, but internal is a little easier to reach the stakeholders
6.1 BUT, scope difference in internal versus external, external expanded scope can add to the worth of the company, internal scope creap can drain resources
7. Agile development can fail if there is no completion, i.e. initial value deliverables don't lead to further value deliverables, i.e. I'm done with this part, I'm going to move on
8. For non profits paying technology, free open source license is really important, to not get screwed by proprietary companies owning your code
9. Important to understand the nature of your open source developers, are they volunteer? can they be held accountable
10. If you aren't getting good "vendor" support on your project, without paid developers, organizations lose control of their technology
11. But when you need to free volunteers, how do you get them and keep them

  a. Conveying to volunteers how their work translates into results
  b. Give users really small deliverables
  c. Really important process, make explicit levels of accountability
  d. Try to find and keep good people by good process

12. Get people invested in projects as soon as possible AND make them aware the process will take LOTS of work, but there is the other side, and when you get there things will be better
3. Language and vocabulary, needs to be the language of the users, must talk to the people info workflow, not tech details

Buy versus build

1. Problem of getting calls of broken databases that nobody in the org knows anything about, and the original tech provider may have gone away
2. Clients want it fixed, the ideal is to give something to the client that can be customized, but the tools can be sustainable
3. The decision is a political one, whether you buy it or build it
4. Always try to avoid building, so many orgs think getting technology is as simple as ordering a pizza
5. A weedy garden is a good metaphor, building your own means lots of bug fixing, maintaining, and most important is security problems
6. Building a website with your own backend these days is crazy
7. Building what the clients expect. Unfortunately also leads to extra expectations of enhancement
8. Clients often think they want to get the perfect software for now and for the future, and never have to deal with it again, need to work to transform that thinking
9. Buy vs build first question is their budget
10. Find people with a track record within your particular industry, and goes with them
11. Avoid single developers like the plague
12. If an org can't specify their needs, their is no way you can build a successful project for them
13. Actually, build versus buy versus bend
14. Only build customization for groups that can handle the technology