One man and his dog build a SaaS — Part 3
A picture paints a thousand words, data paints a million.
Grab a pen and paper then start drawing boxes and lines. In my experience you have to start by thinking about your data when designing a new software system.
‘Data!’ you say - ‘We thought you started by designing the logo for the SaaS!’
Well ok, maybe I did spend five minutes doodling possible logos. But really I need think about what information needs to be captured, monitored and maintained within a project. And consider what that great project manager, Aristotle, suggested were the key questions needed in order to understand any given situation.
Why do we want to do this?
What are we going to do?
Where are we going to do it?
When are we going to do it?
Who is going to do it?
How are we going to do it?
So, my SaaS product should allow a PM to visualise all of these questions and the current answers to these questions.
The ‘Why’ is captured in the ‘business case’ since all projects are about change of some sort. No one ever ran a project where the ‘after’ looked just like the ‘before’, well not deliberately, but I shall come back to this topic later…
The ‘What’ is captured by the product breakdown structure. This upside down tree describes the physics of the project starting with the final finished item at the top and then a breakdown of all the parts below.
The ‘Who’ is captured by the ‘resources’ we have available to the project and HOW? these resources can be allocated to the products.
The ‘How’ and the ‘Where’ are captured by the tasks needed to deliver each product, and again resources can be allocated to tasks and estimates of the task time given.
The ‘When’ is captured by the product flow diagram. This is a simple method to sequence products based on dependencies.
‘But obviously I need a Gantt chart?’ Agreed, but now the Gantt chart is created automatically based on the product breakdown, flow diagram and estimates. By simply keeping the progress reality reported by your resources up-to-date the current project status, Gantt chart and critical path are all produced automatically. Better yet, get your resources to update their progress using a simple mobile app and your project monitoring and reporting takes care of itself. Letting you, the PM, identify and chase the problems immediately.
The key to any good software development is good data architecture. Get your data architecture wrong and you will have continual problems throughout the life of the project and well beyond into production.
‘But what about the logo and the UI and the colour scheme?’ Yes, these are important but if the data architecture is wrong your user interface will be wrong. If you don’t understand the data you don’t understand the customer needs and your UI will follow your data design. That is until you finally realise the UI just doesn’t work for your customer and you end up having to redesign it. Of course then your data doesn’t fit the UI. But the project has now progressed so far you can’t go back, so you have to have use some hack between the data and UI and it all gets messy and complicated. The developers suggest that we’ll come back and refactor later and nervously look out the window at the flock of pigs flying past.
So no, hold the logo and the Sketch or Photoshop UI mockups for now. The picture you need is the data design.
my SaaS can be found at www.puptask.com
