Let’s face it: software development is a complex process that baffles most people. But I make the process simple. I help non-technical stakeholders by talking with them in their language. I then translate these requirements into technical specifications that programmers can easily understand.
My process and documentation assures that everyone is on the same page throughout the entire development process. Since I come from a technical background, I find that technical people appreciate the level of detail I provide. My overall understanding of building applications means I know what the programmers are thinking. At the same time, I understand stakeholders too. By being able to see through the eyes of a stakeholder, I provide the most valuable product within time, budget and resource constraints.
You can think of me as your translator. I bridge the knowledge gap between stakeholders and the people who build applications.
|Summary||What is Done||Deliverables|
|Goals||The stakeholder discusses what they want to accomplish (goals) and together we decide upon a one line description (aka the one liner) of the project or task at hand.||A One-Liner description of the project and list of goals.|
|Brainstorming||We brainstorm features. I will usually use software called Mindjet MindManager to quickly map out ideas.||Notes which are used later in other documentation.|
|Features||We discuss the features and their attributes vs. goals of the project. This is where we pair down the list into things that can be accomplished within the time limit, budget and available resources.||A go-forward list of features.|
|Risk Assessment||We discuss the goals and features and think about what would happen if all the goals or features are not obtained.||A list of “What Ifs” and tradeoffs (i.e. features, time, money and resources).|
|Prioritization||I present the risk-assessed list of features and together we divide the list into attributes relevant to the goals of the project.
|Spreadsheet of features broken down by goal and prioritized.|
|Functional Documentation||I present the high level documentation to the stakeholders for signoff. We repeat all the steps up to this point until this step is complete.||Flowcharts
|Technical Documentation||I meet vendors as needed and the technical director to discuss technical details.||Database entity relationships
Table / field definitions
|Project Documentation||I meet with the project manager to discuss resource allocation and set the development timeline.||MS Project Plan|
|Daily Monitoring||Resources check off items that have been finished.||JIRA or other tracking system updates.|
|Weekly Monitoring||Meet with project manager, technical director to discuss any issues that have come up which may affect the timeline.
Meet with stakeholders if any issues affect the goals of the project.
|Weekly status report|
|Milestone Monitoring||All hands meeting to discuss progress||Updates to documentation as needed.|
|QA Testing||Meet with QA team to discuss testing plans||QA test plan based on all other documentation.|
|User Acceptance Testing||Meet with project stakeholders for a demo of the features supporting the goals.||Updates to documentation as needed.|
|Implementation Plan||Meet with technical director to discuss how we will go live without impacting live systems or required downtime if that’s not possible.||List of systems affected
List of responsible parties
Go live plans
|Go-Live Action Plan||All hands on deck meeting to go over who’s going to do what and in what order and requirements for checking in when each step is complete.||Go-live checklist and assignments|
|Post-Launch Review||We review the successes and failures of the project with the entire team.||Depending upon factors, could include starting a phase 2, sign off on goals not achieved, etc.|