Difference between revisions of "WestCoast2008:PM Principles - Software and Database Development"

From Managing Nonprofit Technology Projects Wiki
Jump to navigation Jump to search
m (1 revision imported)
 
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
Notetaker: Mark
 
Notetaker: Mark
  
 +
===What people want to talk about===
  
===what people want to talk about===
+
1. How to choose tools<br/>
 
+
2. Documentation and QA<br/>
1. how to choose tools<br/>
+
3. Managing people, especially not full time<br/>
2. documentation and QA<br/>
+
4. Managing times<br/>
3. managing people, especially not full time<br/>
+
5. Managing software projects rather than websites<br/>
4. managing times<br/>
+
6. Research on things that have worked<br/>
5. managing software projects rather than websites<br/>
+
7. How to plug in volunteers<br/>
6. research on things that have worked<br/>
+
8. Bill versus buy questions<br/>
7. how to plug in volunteers<br/>
+
9. Scope and scale<br/>
8. bill versus buy questions<br/>
 
9. scope and scale<br/>
 
 
 
  
 
===Gunner's intro===
 
===Gunner's intro===
  
generalizations<br/>
+
Generalizations<br/>
1. prevelant 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<br/>
+
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<br/>
2. connect with peoples' pain and passion<br/>
+
2. Connect with peoples' pain and passion<br/>
3. to avoid, Agile development is encouraged, partnership with passion, work with people during the difficult parts to encourage a painless final outcome<br/>
+
3. To avoid, Agile development is encouraged, partnership with passion, work with people during the difficult parts to encourage a painless final outcome<br/>
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<br/>
+
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<br/>
5. all successful tech projects work on the same model of the community organizing model<br/>
+
5. All successful tech projects work on the same model of the community organizing model<br/>
6. do these apply to internal projects? the answer seems to be yes, but internal is a little easier to reach the stakeholders<br/>
+
6. Do these apply to internal projects? the answer seems to be yes, but internal is a little easier to reach the stakeholders<br/>
 
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<br/>
 
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<br/>
7. agile developemnt can fail if there is no completion, i.e. initial value deliverables don't lead to furthur value deliverables, i.e. i'm done with this part, i'm going to move on<br/>
+
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<br/>
8. for non profits paying technology, free open source lisence is really important, to not get screwed by proprietary companies owning your code<br/>
+
8. For non profits paying technology, free open source license is really important, to not get screwed by proprietary companies owning your code<br/>
9.important to understand the nature of your open source developers, are they volunteer? can they be held accountable<br/>
+
9. Important to understand the nature of your open source developers, are they volunteer? can they be held accountable<br/>
10. if you aren't getting good "vendor" support on your project, without paid developers, organizations lose control of their technology<br/>
+
10. If you aren't getting good "vendor" support on your project, without paid developers, organizations lose control of their technology<br/>
11. but when you need to free volunteers, how do you get them and keep them<br/>
+
11. But when you need to free volunteers, how do you get them and keep them<br/>
   a. conveying to volunteers how their work translates into results
+
   a. Conveying to volunteers how their work translates into results
   b. give users really small deliverables
+
   b. Give users really small deliverables
   c. really important process, make explicit levels of accountablity
+
   c. Really important process, make explicit levels of accountability
   d. try to find and keep good people by good process<br/>
+
   d. Try to find and keep good people by good process<br/>
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<br/>
+
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<br/>
3. language and vocabulary, needs to be the language of the users, must talk to the people info workflow, not tech details<br/>
+
3. Language and vocabulary, needs to be the language of the users, must talk to the people info workflow, not tech details<br/>
  
 
===Buy versus build===
 
===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<br/>
+
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<br/>
2. clients want it fixed, the ideal is to give somethign to the client that can be customized, but the tools can be sustainable<br/>
+
2. Clients want it fixed, the ideal is to give something to the client that can be customized, but the tools can be sustainable<br/>
3. the decision is a political one, whether you buy it or build it<br/>
+
3. The decision is a political one, whether you buy it or build it<br/>
4. alway try to avoid building, so many orgs think getting technology is as simple as ordering a pizza<br/>
+
4. Always try to avoid building, so many orgs think getting technology is as simple as ordering a pizza<br/>
5. a weedy garden is a good metaphor, building your own means lots of bug fixing, maintaining, and most important is security problems<br/>
+
5. A weedy garden is a good metaphor, building your own means lots of bug fixing, maintaining, and most important is security problems<br/>
6. building a website with your own backend these days is crazy<br/>
+
6. Building a website with your own backend these days is crazy<br/>
7. building what the clients expect unfort also leads to extra expectations of enhancement<br/>
+
7. Building what the clients expect. Unfortunately also leads to extra expectations of enhancement<br/>
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<br/>
+
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<br/>
9. buy vs build first question is their budget<br/>
+
9. Buy vs build first question is their budget<br/>
10. find people with a track record within your particular industry, and goes with them<br/>
+
10. Find people with a track record within your particular industry, and goes with them<br/>
11. avoid single developers like the plague<br/>
+
11. Avoid single developers like the plague<br/>
12. if an org can't specify their needs, their is no way you can build a successful project for them<br/>
+
12. If an org can't specify their needs, their is no way you can build a successful project for them<br/>
13. actually, build versus buy versus bend<br/>
+
13. Actually, build versus buy versus bend<br/>
14. only build customization for groups that can handle the technology<br/>
+
14. Only build customization for groups that can handle the technology<br/>

Latest revision as of 22:41, 14 January 2016

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