Failing of Projects and Growing Forward

First, there is no such thing as an ideal software product. But we are striving to achieve one while being deeply passionate about it. However, there are a lot of factors and situations that can impact product output.

Balance right round like a record, round, round

Let’s say we have a clean start, a new project kick-o. Where to begin?

Pointing obvious but most important key factors:

• project goal definition


• balance workload with the massive support of each team member


• aim to short-term goals


• transparency over deadlines, expectations, and risks


• change is the only constant during a delivery

Ran into this piece of art at Tisja’s Kljakovic Braic exhibition held in 2021. It perfectly matches some daily challenges we all have, both in private and business life.

I would dare to say that as of an uprising era in software development, the spinning moment is most tangible through development delivery.

During a project, each of us has a spinning role. We spin those records right around and try to achieve the final result while (hopefully) aligning and mutually understanding each other. That’s why it’s always good to ask questions and challenge actions.

Of course, we are humans, after all, so it’s natural we make mistakes. Or we need a new solution for a change in the backlog. Or simply current output is not good enough for delivery.

And that’s where the balance of activities, workload, and team eort is crucial to happen. Therefore, every team member should deeply think of it while approaching problem solutions and delivery.

Product health check

At the beginning of the project, a crucial moment is product roadmap definition where one rule applies: without vision, there is no valuable output. A great example of inspirational leadership and visionary approach is Stewart Butterfield’s Slack memo sent internally a week before launching the application.

When starting, it’s important to meet the team with a vision, a high-level overview of the product and diagnose product value, challenges and approach.

For instance, we have a client who wants to build a web-based application for contracting car insurance online, and managing insurance afterward.

In parallel, the client desires is to engage employees with the new application and educate them on product dierentiations as the market is constantly changing. Their primary focus is on introducing internal and external users with insurance portfolios and oering the best possible personalized proposal. The intention is to generate new leads and extend the potential market. Mostly, users are approaching from mobile devices, so the application needs to be fully responsive.

Before project kick-o, the client made an internal market fit hypothesis, benchmarking, and strategy definition. The goal is to put an application in production in 4 months.

Note: Examples and data used are fictional.

Goal settings:

• Raising awareness on vehicle insurance portfolio


• 3000 new leads in Q4

Diagnosis:

• Educate employees at branches


• Vehicle insurance portfolio – min 3 products available


• Calculate insurance price


• Integration with 3rd party providers (car insurances)


• Multi-language support – English, French


• Compliance and regulatory needs – unknown at the moment


• Managing insurance products online


• 80-90% of users accessing from mobile devices


• Responsive web-app

Roadmap definition

A key metric when thinking of roadmap and backlog definition should be scaling feature size to determine priorities in the time given for delivery.

In the following example, the size of the feature outlines importance while the order of the feature outlines priority for development. This way, everyone gets an overall, bigger picture.

Whole beauty (or madness:)) behind ongoing development projects is to generate new ideas and approach each product solution dierently. That’s how innovations happen. One great resource on dierent approaches for defining a roadmap can be found in the Department of product guide.

The client stated that vehicle insurance proposals and educational materials are valuable application assets. In contrast, the dashboard and managing insurance are prioritized last and can be postponed for later phases.

Important note: even though it sounds like everything is a top priority for development, it honestly isn’t. Use groomings and informal discussion to distinguish between should have and core value features.

Successful vs. failed sprint

In the given example, the first thing for the backlog is the onboarding flow related to the insurance proposal.

The main scenarios revolve around:

• Give license plate for registered vehicle


• Find vehicle


• Give personal data


• View insurance prices and options

During the sprint, the idea is to get design and functional approval and start initial development activities, including project setup and user interface implementation.

Many things during the sprint can go wrong, so it’s crucial to define core sprint deliveries, often collaborate and ask questions even more. The worst-case scenario would be to have in sprint features and user stories that do not have enough prerequisites in terms of priorities and decisions needed. This leads us to lack motivation and not get things done precisely.

During the sprint, we realized the lack of inputs to get insurance prices and integrate with the 3rd party provider. Reasons are legal regulation changes for traic road safety and technical gaps:

• Does a user need to sign an application to generate an insurance proposal digitally?


• How do we calculate and fetch dierent insurance proposals?

That’s why the decision was to exclude insurance pricing from the sprint and add Knowledge base flow.

Scenarios include:

• Define document management system (internal) – knowledge areas and metadata used


• Research on search engine implementation and optimization

As sprint output, we showcased partial onboarding flow and presented findings on knowledge base flow. What have we learned out of it? It’s okay to accept changes during the sprint but more important to trace what was done and what was descoped from the planned sprint, including reasons behind those actions.

What was not so good in this sprint? Desire was to round up the onboarding flow, but we could not adapt to the new situation due to circumstances. For the future, the idea is to stabilize flow in development. A closely engaged client is needed to raise awareness of all risks and eects on the outcome.

Tip: Be consistent, aim for a short term goal to have a clear output of one sprint rather than having too much work which will not be done. If in one sprint you can’t summarize 5-8 bullets what was done then the sprint should be treated as a failed one.

Transparency and changes

To think of transparency, let’s put it this way – have you seen the good output of products when information and insights were hidden from team members involved in its delivery? In fact, how to get people to trust and love what they do with applications being developed if they don’t get all pieces of information?

The biggest challenge is communicating changes and understanding what was aligned before the development started and what was changed. That’s why data analysis must always be traceable.

All facts, insights and valuable knowledge lie in data and the only question is how and when it is presented? This brings us back to the balance of workload and team eort previously mentioned that must be achieved. However, everything is doable with wise, timely communication of needed parties.

Conclusion

It’s okay to fail or succeed in the project, but learning something is the most valuable asset. During development, don’t be afraid to ask any questions, communicate unknowns, changes, and balance, always balance. Right round, like a record, round round. 🙂

Or, if in doubt about how to achieve all points mentioned, feel free to reach us to help you!