Software Project Planning
In my previous post of the "back to basics" series, I wrote about software testing. If you'd like to read it before proceeding, click here.
I've observed many projects and I had been the de facto PM in a few of them. If you are in a start up or a small team, where you don't necessarily have a project manager, this guide could serve you well.
This post discusses the discovery phase of a project, it is concerned more with capturing requirements and perhaps it intersects with product management.
First, Understand The Problem
What problem are you trying to solve? The more you examine and understand the problem, your odds of finding an appropriate solution with minimal resources increase.
From previous observations, I found that projects struggle or fail primarily because the client did not define the core problem well (leads to scope-creep) or did not provide clear-enough parameters (extends timeline).
Examples of past problems I worked on:
"Maintaining a product catalog for each country is onerous and tedious"
"Calibration and diagnosis process of a system is mundane and time-consuming"
"Process of returning defective goods to a supplier is redundant and cumbersome"
The Process
I have noticed that projects can succeed if the following specification-triad are on hand:
Below, I describe how these steps can help bring about a successful outcome.
Workflow Diagram
One way to analyze a problem is with a diagram that describes the business process of concern. It would illustrate the problem in a definitive manner. It could also help derive a solution or discover potential improvements, and become the basis for business rules developed into the software.
The diagram can be manifested in various forms: workflow diagram, use-case diagrams, decision tree, flowchart, etc. Regardless of name, it should detail the present process.
Below is an example of such a diagram from a recent project (this is a derived solution).
I find it easier both for me and the client to pin down problems and requirements with a flow diagram than speaking of concepts or abstract notions.
Product Design
In the product design phase, details of deliverables are set in stone, and requirements are honed and refined further, reducing the chance of misunderstanding or misinterpretation of expected outcome. It also makes the deliverables more tangible.
Below are examples of mock-ups that were designed either by me or some colleagues.
Recommended by LinkedIn
Visual mock-ups are a cheap way to change requirements or find any blind spots missed in previous steps (i.e. skip the need to iterate thru a number of releases to discover them).
Entity Relationship Diagram
I mentioned in a previous post that software processes revolve around data, hence, the importance of understanding the data and how you model it. An ERD should be the first technical task you undertake, because if you get the data model right, the remaining technical tasks would fall in line almost seamlessly. The data model does not need to be complete, but should be extendable (i.e. normalized).
I usually find a schema diagram to be sufficient and achieves the purpose (illustrated above).
How to Detail Technical Tasks
Thru the years, I observed software teams try various ways and methods to improve project estimation, and none seem to add more accuracy. The one variable that helped bring more accurate results is the granular definition of technical tasks.
How do you go about defining as task? give this a try:
Below is an example of task details (in case of a bug, you may add "steps to reproduce").
The acceptance criteria should not be (and usually is not) negotiable. But technical implementation should allow room for discussion on an optimal solution. Acceptance criteria can also be a guide to additional automated tests, and the more you apply and enforce testing, the easier it is to iterate thru future changes.
When proposing a solution, it is tempting to find the easiest path. But that could lead to blind spots that may require substantial follow-on work. Instead, creating a solution with a cynical mindset of what-could-go-wrong and an eye on dependent components can provide a more broad and comprehensive enough solution (but no necessarily exhaustive or perfect).
A Note on Project Planning
I like to groom tasks before a project or development cycle kicks-off. I fill in necessary details, and set parameters to any further discussions. This helps reduce lengthy discussions and debates. Open-ended brainstorming never end, and nothing can slow a project's velocity than a good dose of lengthy meetings.
I also practiced having weekly touch-points with stakeholders after project kick-off, and increased the frequency of these engagements the closer we get to delivery deadline.
Summary
Being agile and being precise are not contradictions. This process is simple and agile enough but also adds greater rigor and compliance to a project.
A picture is worth a thousand words
If you detected emphasis on visualization in the process above, you are correct. Visual aids can narrow the risk of spending countless man-hours playing a game of telephone, attempting to interpret what it is to be done. It also reduces the need to type lengthy and wordy textual interpretations (I've always hated reading such documents).
Armed with the process and information prescribed above, confidence in your project should go from 0 to a 100 real quick. Give this approach a try and let me know how it goes.
And as always, do it once, and do it right.
