Previously, we discussed some popular myths and misperceptions people have about software development. Now, let’s take it further by talking about how you can make the most out of your software projects.
Choosing The Right Software Developers
In addition to the key pointers we’ve outlined in this post (Dos and Don’ts of choosing software developers), the concept of “fit” is worth mentioning here.
We as humans are drawn to those who are similar to us and share the same values. In the context of professional recruitment, there is a potential bias as we tend to choose people who reinforce our worldview (or selective exposure).
On the other hand, you might flinch on hearing shortlisted developers challenge your concept in an attempt to expand your worldview.
Source: Wake Forest University
Sometimes it is a line between your rational thinking and their outrageous fiction. But sometimes, it is between your comfort zone and their innovative approach that could make your software project much better.
Thus, look for something that fits, but still leaves enough room for innovation.
Trust
Once you have chosen the right developer, it’s important to start building trust by practicing mutual empathy. When developers remember that their clients have corporate masters who demand results, and when clients remember that the developers might overwork themselves to meet changing requirements - then empathy can be built.
Source: Limebridge
Moreover, from a practical point of view, repeat business is always better for developers, which means there is more in it for them to complete your project successfully than dragging it out for extra charges.
Identifying The “Job”
This is where you create a shared sense of purpose, not only between your software product and end-users, but also between you and your developer.
Essentially, you should be able to articulate your answer to the question: “What job would people use your software to accomplish?”
This is a multi-faceted question in the Jobs-to-be-done approach to product innovation, which we’ve covered in a previous blog post.
Hence, identifying this “job” needs input from both sides, as it will help determine:
- Scope
- Functionality
- Budget
- What development methodology/practice to use
Note: Sometimes, the original job changes as users discover new ways to use your product. So does that mean it’s pointless to uncover what they want to achieve with your software in the first place? The answer is no.
Consider today’s biggest social networking site and how it started out. “Thefacebook” was well used and loved before users extended it to other purposes, e.g. broadcasting their own emotions and activities to their social circles.
Facebook’s original “job” - Source: thejournal.ie
Software Project Estimates
As mentioned in the previous post, one of the most prevalent myths in software development is you can get a 100% accurate time estimate.
There are two reasons (which we’ll go into more details shortly):
- Issues from estimating methods
- Issues from internal and external environments
The coastline paradox
How long do you think the Australian coastline is? Is it around 12,500km or 25,700km? The wide discrepancy is due to the different approaches used to measure the coastline. As you go deeper into the level of detail - or use a shorter ruler - the coastline length gets longer.
Source: Dick Whitaker
What does this have to do with software project estimates? If you want to get a rough estimate that doesn’t take long to do, you might discard the important details that will come into the picture later on.
The takeaway here is: Unless you want high granularity level from the start, the actual software development time is most likely longer than the estimates.
Factors that could make project deviate from estimates
The table below contains examples of factors within and outside of your business that could stretch your project timeline.
Best practices
Given the above, it’s better to consider estimates as guidelines rather than hard-and-fast rules. Sometimes, the efforts spent on coming up with estimates can eat into valuable development time.
- Break a project down into small sets of useable features prioritised by value.
- Re-evaluate the plan and estimates after each deliverable.
- Fixed price = high price (pushing the risk onto developers means they will pass that risk as a cost onto you)
- Small milestones and constant renegotiation improve communication and help share the risk to give a better outcome for everyone.
Don’t set unreasonable goals
Most projects that end late, started late. Start the project early to ensure you provide ample time in the end for tasks such as review and changes. If you have a deadline to meet, allow up to 2-3x the expected time period.
Identifying Risks
Following from the previous section, identifying risks help you account for errors in estimates and manage them better.
Note: Decide if your project’s potential value outweighs the risks. If not, then re-evaluate the goals.
Referencing the often quoted book - Waltzing with Bears: Managing Risk on Software Projects - we’d like to point out the key action items:
- Identify, track and label risks
- Find trigger conditions for each risk
- Define impact and mitigation strategies for each risk
- Estimate risk probability: Account for this in the project estimates, some or all of the risks will occur during development. Estimates should always be described as a probability profile - least likely lower estimate, most likely and least likely upper estimate, e.g. 3 days - 8 days - 15 days
- Calculate value impact should the risk eventuate
- Discover showstopping risks that will derail the project should they eventuate and ensure you are OK with them. Find ways to remove these if not. These become the underlying assumptions of the project going forward.
- Ensure all components and parts of the system are defined early on in the project
- Monitor and re-evaluate the list of risks regularly (at least at each deliverable milestone). Execute contingencies as they are triggered.
- Add new risks are they become apparent
It’s better to consider software estimates as guidelines rather than hard-and-fast rules.
Don’t try to make the perfect product (or Don’t “gold-plate”)
Borrowing from the lean methodology, once you’ve identified the Minimum Viable Product (MVP), try not to over serve and waste budget/time on things that customers will not value.
An example is spending your energy on nice-to-have features, such as social sharing function for a corporate time tracking app.
Thrash upfront
To implement a lean approach, do a bulk of the discovery and invention upfront, experiment with small bits throughout.
Make sure all important stakeholders are included early, then increasingly reduce the amount of influence these stakeholders are allowed to have across the project. This is to minimise bureaucracy as well as empower project personnel to achieve the project vision.
Project Management
Accountability
Keep track of roles and responsibilities but don’t over-document everything. For example, you don’t want to implement the US Department of Defense documentation style: 25,000 lines of software code could easily require 5000 – 10,000 pages of paperwork.
Sometimes, visual/graphical representation does a better job than word documents. For example, here at Enabled, we often use app maps and wireframes to document the development process.
Example of an app map we did for our client (click here for complete image)
Communication style
It is both common sense and good project management to have periodic review and re-estimation. Remember the “coastline paradox” mentioned earlier? As you gain a better understanding of what you’re dealing with, subsequent estimates might be more accurate.
In the worst case, over-communication is better than under-communication. Why? Because having to undo the hard work already put in, or risk having cost overrun is a much bigger problem. That said, the most effective communication:
- Is two-way (rather than one-way reporting)
- Is timely
- Is directed to the right stakeholder who has authority to act promptly
- Is comprehensible by the receiver, i.e. not full of technical jargons
- Is delivered using the most efficient channel (e.g. email, phone, face-to-face)
- Fosters team spirit across different organisations/teams
Don’t over-staff
We’ve mentioned Brook’s Law in our previous post but it’s worth noting it again here. If you need a lot of people, get them BEFORE the project starts.
Testing
Let’s briefly look at the different kinds of software testing:
- Automated unit testing increases development cost by 30-50% but reduces the number of bugs by up to 90%. This is done throughout the project, not just towards the end.
- End-to-end testing tests a fully integrated system as if a user was using it.
- Staging environments allow changes to be heavily tested by users before deploying into a production environment for general use.
Note: Developers should not be testers in the project they are working on, as their familiarity with the software may skew the results (similar to how writers have proofreaders/editors). Also, depending on the project’s complexity, role specialisation can increase efficiency.
What If You Want to Change Something?
Change requests and how to minimise disruptions
Consider dividing the project into sprints - short fixed feature milestones. Then evaluate and change after each milestone.
Note: Regardless of the scale, it’s crucial to assess any impact of change and obtain appropriate approval.
- Small changes that don’t have significant impacts on solution architecture: can add up over time and derail the project if not controlled properly.
- Big changes: refer back to Jobs-to-be-done. Would this help the user solve anything?
Say no to new ideas towards the end of project
If you have considered all the factors mentioned in the above sections, last-minute changes are highly unlikely.
However, if “The Sudden Go-Live Realisation” hits you, resist the urge to ask for changes that could potentially break the system if rushed. In fact, last-minute changes are among the top 10 reasons that software has bugs.
Consider moving those changes to the next phase after gathering enough user feedback. This would help you stay within your desired time frame for the current project, as well as refine your new ideas for the next project.
Looking Into The Future
Does a software release mean the project is done and dusted? Not necessarily. The best software is something that receives constant care. Even if you are not a technology company, the fact that “software is eating the world” means you need to keep improving in order to remain indispensable to customers.
Maintenance
Security updates, bug fixing and regular maintenance ensure a smooth performance of your software product - just like how you take your car for a log book service.
Additionally, having a Service Level Agreement (SLA) with your developer gives you peace of mind that technical issues are ironed out as soon as they crop up.
Small milestones and constant renegotiation improve communication and help share the risk to give a better outcome for everyone.
Enhancement
This is how you prepare to take your software product to the next level, grab market share or fend off disruptors. Consider product improvements with information gathered from:
- User feedback
- Industry responses
- Emerging technology trends
Slack - the enterprise messaging app that went from $0 to $1B - is a result of serious commitment to product enhancement.
They weave customer support and product development into their strategy. “Slack responds to around 8,000 Zendesk help tickets and an additional 10,000 tweets per month” and more importantly, learns from them.
