Managing Custom Database Projects

Description

Designing and implementing custom developed database projects is one of the most difficult kinds of technology projects that one can do. How can you make this process a dream instead of a nightmare? How can you get the information from stakeholders, work with vendors, train staff, and make the process move smoothly and on schedule? We'll share experiences, ideas and best practices.

Session Notes

Notetaker: Margot

Eric asks for a go around on what our database experiences have been.

Eric throws out a definition of what a custom database is and checks to see if we agree that managing these is difficult.

Troubles are things like staff turnover or loss of a long term maintainer, pressure and expectations are really high, the idea it can do anything. Data growth and loss of perspective on what's really in the databases. Security is also often a huge concern because sensitive data.

Eric asks us to tells some stories about security trouble. Tanya tells us about an experience at move on, like rate limiting access to data. Eric talks about the scope being so broad, struggles to keep folks from just giving you an open ended idea of security.

Tom suggests that user stories and use cases are really useful for inferring security levels and use goals. Eric adds to that he often brings them into a group to identify how often that people are using the same information but think of it as different.

Eric ask how we estimate scope of the project, Anna talks about her experience working with developers over a long time give you perspective on how realistic their estimates are. Ian asks, how do we gauge for the unexpected, no one seems to know.

Melinda talks about the fact that people don't expect thing to be on time exactly.

Tanya talks about her hope that you will tell her rather than pretend since she might then decide to scrap that feature.

Tom suggests that prioritizing things is super important to that and being clear about what is possible.

Anna talks about her engineers want for good detailed descriptions.

Eric talks about estimations and the ball park with a motivator to go through a good spec because "we think we can get the cost down to x with good spec'ing"

Mark talks about good introduction planning and approaching scope as a good intro planning phase.

Ian tells stories about, how quickly you can be sucked into trying to do everything when you are working with people with big idea's.

Hanna talks about using the trade off, making sure that people know that features are often a trade off. as well as identifying what is core functionality.

Eric suggests over delivery and under promise.

Debbie suggests that bringing in developers to a meeting sometimes gets you a little more realistic expectation from visionary leaders.

Eric suggests a to-do list as a just a good model for keeping the scope clear, ask about peoples experiences using some other ideas for keeping long projects in scope.

Eric if you are a user who understand the technical side of things it will help you a lot more when you get into the testing phase. Eric, asks when do we get into the testing phase, many folks talk about doing testing earlier.

Melinda says a lot of the ideas for testing through the project could be very expensive. Hanna suggests that checking in can be time consuming and so getting feedback regularly can be very hard because the testers are busy.

Eric talks about ways to model the idea as a test. Ian says you are testing the person not the code.

Tom talks about the big picture being really important for clients to see the big picture so that they will get an idea of what have been missed.

Hanna talks about making them think through all the reports, making them think about what output or report they will want early on.

Tanya suggests that they often forget about the reports until after the data has been collected. Eric talks about a pivot table in access as a three-d mix and match.

Eric asks us about communication styles.

Bergan talks about doing interview after interview and gets people together and really gets them to flush out what people really want and to keep them abreast of what they can and can't have.

Hanna suggests a weekly email report of what people are doing. Catherine talks about using instant messenger or Basecamp to keep up really up to date in the moment.

Mike talks about using the application camp fire.

Eric talks about always using a follow up email after any phone conversation that summarizes the details of the discussion and to do a regular checkin over the scope/spec/contract document.

Tom talks about the fact that often simple verbal agreements often change the original RFP alot by the end, this keeps clients happy and give them a product they are happy with an use.

Bergen suggests that you should add to the RFP rather than verbal agreements. some folks suggest that there is usually a simpler paper trail.

Tanya asks what kinda language you would use to describe the project.

Eric defines RFP (request for proposal), RFQ (request for quote), RFI (request for information). He suggests that you be really clear in an RFP about what the basic challengers are and what format you want to see the response. He also says that in response to the RFP you should include the scope creation as a part of the quote. Others talk about keeping that range in the doc as a good way to keep the client aware that creating scope will be what effects

Tanya asks what is scope. Tom answers that it is a very detailed description of the project.

Anna talks about scope docs as being really detailed down to each page.

Mark talks about specs as being more about the actually technical requirements, what technical things need to happen.

Eric talks about a spec as being rewritten by contractors and developer as a part of any process.

Tom says that scope is implementation path while spec is more a general itemized list of technical points.

Eric says know your audience and asks us about how we say a project is done? Bergen talks about doing versions as important to keeping features from creeping into the path.

Anna talks about training and documentation as being an important part of ending the project.

Eric suggests that we talk about the end date or launch date about half way through the project and suggests bringing in someone who has the budget in mind to basically say ok the project is done and is over or under budget.

Anna talks about how projects never really end because people can always think of something else they might want.

Tom talks about how sometimes clients don't realize that the time we set aside for them in the production pipeline is gone and you have to put them off.

Eric asks us to talk about data migration challenges and ideas.

Folks talk about the use of a little sample data early to get things up and running and give the client something to see what that data is really gonna get moved and where. Eric talks about data cleanup and how it's a partnership to clean the data.

Anna asks folks for any kinda data checking and cleaning ideas folks have had for getting people to go clean their data up. Tanya suggests a contest to get staff to do tedious things, like giving away iPhones for uploading data