Recently I've found myself in a frustrating situation at the office, and it was ALL MY FAULT!
I am the only developer for nearly a one thousand person agency, that provides disabilty related services. My developer position is relatively new, the company had never worked with a software developer before me. We have a few smaller projects in different stages of completion; several have been fully executed and have gone through the enhancement cycle, others are just entering the concept phase, and a others have just been accepted and released. Most of these projects were small, with a clear concept and plan for execution. Several where my own concept where I oversaw the entire project.
Then steps in my current project, a massive, complicated, beast of a project. The initial concept sounded simple enough;
"Ben, build us a timeclock web app... "
"Let's have staff be able to clock in on the web. Let's have it be compatible with our existing processes. Maybe you could attach it to our current corporate intranet. I think the logo should be blue. It would be cool if this could handle the medical billing too. What about calculating and paying mileage? Maybe we can track pay rates here? Is this going to be secure? I think staff should be able to clock in over the phone so we can verify attendance. I am really liking this idea, we can develop it ourselves and have Ben make it do anything. Why don't we have it track authorized hours for our clients too."
"Great, sounds like we have a solid plan. Good Luck Ben! Think we will be ready to test in 3 months?"
I took some notes and had a pretty good general idea of what we wanted to happen; commence 3 months of furious coding, testing... ANGRY ANGRY typing. Huge success. Dismal Failure. Distractions, other projects... more coding.. Until yesterday when at an unrelated meeting the scope of the project changed, drastically. I lost it. Sitting across the table from my boss and his boss, I very nearly said some unkind things, instead I skulked back to my office, defeated, and did some thinking. I did a bit of googling and reading about Project Management, "How to work with a developer", "12 Pitfalls many developers fall into", and the Software Development Life Cycle (SDLC). I read a few articles about SDLC and it became clear, we had skipped a few steps. We jumped from concept straight into code. I was doomed to fail. I had failed to guide them through the appropriate steps for software development, they didn't know better but I did, this was on me. I had let proper procedure slide on other previous projects because they were small, clear, or my idea. This project was different at it's core. I failed, I was responsible to guide them into creating a plan that would allow me create great software, I should not have moved forward with out this plan.
Having identified the issue, I set forth trying to correct my blunder. I quickly drafted an email to my boss, I expressed my frustration in a clear and non confrontational way.
"I've been more or less been given free reign over this project, essentially dictating to myself what needs to be done, doing it, and evaluating my own success: Having not been given definite specifications I am essentially the client, more or less defining the project specifics, I am the project manager, I am writing the code, I am testing the code and evaluating it's usefulness."
Thankfully my message was well received, I am incredibly luck to work with some great staff. My boss and his boss both responded quickly, arranging meetings, identifying staff to serve on a committee, and all around being very supportive. They both understood my email, understood why we'd need to comprehensively define a detailed plan.
"I've come up with a few ideas about what I think we can do to improve the process to make this project smoother and my work more reliable.
- First and foremost: Be Specific. I need clear and detailed explanations of what, how, and who. I need to understand existing processes and procedures, and future goals. These should be defined TO me by the end users.
- Define a specific Minimum Viable Product (or "MVP"). Have your MVP spec'ed out and ready to be built. And make it small. If you designed a giant app (which we are), break it down and start with one part. Ship your MVP-and then change your mind based on data (testing).
- Set Goals, Not Deadlines: In the technical world, deadlines don't always work. Even the most experienced developer breaks stuff, and estimating how long it will take to fix things is hard. Each Goal can be accomplished or have its progress measured. The current "goal" for this project reads something the lines of "does everything that 30 current distinct and discrete processes and procedures do, without the kitchen sink, but with a little bit of magic". I have a broad overall understanding of the process and goal. Again, specifics.
- The requirements that your dev receives will be the ones that he uses to start working. Changes to the requirements may be unavoidable in certain cases, but the norm should be delivering the finalized request.
- Outline your measures of success: Share with your developer the high-level measures of success that you'll be looking at after the project is launched.
- Use of project management system to measure, document and track each individual goal, step, progress toward the MVP, and each individual process and procedure that will need to be replicated in code."
So, now I've set my expectations, they have bought in and are on board, they were easy (Manager of IT and the Director of Finance). Now to explain this process to the rest of the staff involved, most of which are much less technical. How do I teach these staff about the Software Development Lifecycle? How do I get them to accept my process? I'm now starting to build some presentation materials for a series of upcoming meetings with these key staff.
Next we need to drill down into our general design requirements. how will we use it, how will we access it? What data are we going to be inputting, who is responsible for entering it, how is it viewed, verified, what are we going to do with it?
From that we build a detailed design plan, this for the most part, needs to be very detailed. Needs to be specific procedures, data flow charts, data models, views and controllers, specific operations. This step needs to define each individual step and component. The more detail we insert here the less surprises we find during the development process.
Once our detailed plan is in place we can move on to the actual development. As each unit is completed and tested it passes through a validation loop; "do these test results match what we expected from our detailed design plan?". As each group of units is completed into full components, they too pass through this validation loop. "Is this doing what we need it to do?" This allows us to loop back through portions of the design process, back through development and back up through testing again until we meet the requirements of the overall design.
There will always be questions. There will be changes. There will ALWAYS be hiccups!
Once the development and testing is through we prepare for project delivery, we inspect the project as a whole. "Does this do what we expected, are users going to be able use this for what we intended". It's still ok if we miss the mark here, it happens. Once accepted the project passes into the maintenance and use phase. If we did our due diligence, this should go smoothly.
Once the project is deployed, processes and needs may change, these changes don't reflect back on the project planning and development as a failure. These changing needs just trigger the lifecycle to start over again.
Your boss, your clients, may not understand the need to hammer things out before we start the development process. It is your job to make them see the value. Don't skip the steps... you'll regret it. I know I did.