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-off. 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 Kljaković Braić 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.

Tisja’s Kljaković Braić — The man turning the board, 2021

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 effort 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.

Product high-level overview

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 differentiations as the market is constantly changing. Their primary focus is on introducing internal and external users with insurance portfolios and offering 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-off, 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.

Size scaled roadmap

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

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.

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 traffic 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 different 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 effects 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.

Sprint formula

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 effort 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 a 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!

--

--

--

Surrounded by good music and mountains in my free time. Truly loving product launch and that spinning moment prior to production.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Cara Mengakses Sensor PH Atmega CVAVR

Cara Mengakses Sensor PH Atmega CVAVR

Running automatic tasks in .Net Core WebAPI

The benefits of Creating a SPACE on the KeplerSwap DEX

How to get CA Certificate of any server using Google Chrome

The Secret to Being a Top Developer Is Building Things! Here’s a List of Fun Apps to Build!

What I learn from experimenting with Docker for web development on Linux. Part 1

NFDI4Ing — National Research Data Infrastructure for the Engineering Sciences

DOOM fire effect in C# running on Windows NT 3.51

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Maja Kostić

Maja Kostić

Surrounded by good music and mountains in my free time. Truly loving product launch and that spinning moment prior to production.

More from Medium

Importance of effective Talent Management for Business growth

Applying fundamental principles of problem solving to rewards and organization consulting

Instagram’s Product Tags are now available for all users

Ramadan from a Value Stream