Power of Vision: Workshop Roadmap

Prelude

Starting afresh is always exciting, but it often entails navigating through uncertainties. When Pentech approached us, they had a project vision in mind and looked to us to make it happen. However, before implementation, we focused on understanding their vision and creating a practical plan. This led us to rely on workshops: these group meetings, involving key people, were crucial for our project plan. Through brainstorming and careful discussion, workshops laid the foundation for our success.

Recognizing the significance of the initial workshop was critical despite its lack of direct involvement in coding. It served as the foundation for project planning and precise cost estimation. As we move forward, we'll explain how we turn ideas into solid plans. From understanding user needs to setting timelines and budgets, each step brought us closer to delivering excellent software.

Join us as we explain how workshops shape our projects every step of the way.

Stage 0: Initial Vision

In the early stages, we aim to get a bigger-picture view of our clients' needs. We sit down with them and dive into their business operations. We want to understand their priorities without getting bogged down in details. These initial meetings set the stage for the rest of the project, giving us a solid foundation on which to build.

With a clear understanding of our client's needs and priorities established in these initial meetings, we're ready to zoom in.

Stage 1: User Stories

User Stories guide our project, telling the story of what users need. They are crucial in representing how users engage with the system. They typically follow a structure: 

‍"As a [user type], I want [ action] so as to [benefit]." 

It's our way of illustrating how we envision the system operating and ensuring alignment with our clients.

Think of user stories as sticky notes linked by arrows that show the user's navigational path and achieve specific outcomes. These paths can include looping scenarios, where actions are repeated until certain conditions are met, or branching, where different actions lead to varying results.

For us, User Stories have been the bedrock of our project. They have given us an initial framework that has grown thanks to daily, sometimes multiple, meetings. Post-discussion, we have gathered new requirements, created new User Stories, and refined existing ones.

When outlining each potential user interaction with the system, we treated it as a separate User Story for clarity and communication purposes. There were no assumptions. All parties needed to understand precisely what the user could accomplish through the stories. Most of the remaining discussions were about the "how" rather than the "what."

However, these User Stories were only the first step of our process.

Stage 2: (Not so) lo-fi mockups

Low-fidelity prototypes, often humorously referred to as "napkin sketches," offer an essential representation of how elements on a page interact or contribute to the overall flow of an application. They're deliberately simplistic and cost-effective, focusing on the website's appearance and functionality.

However, our project took a different approach. Our mockups contained more detailed content, offering a comprehensive view of each page's composition. Using Figma, we crafted mockups that allowed us to navigate through the application's flow seamlessly. These mockups didn't emphasize visual aspects like colours or styles but provided a holistic sense of the application's functionality, ensuring alignment with the client's requirements.

This step proved beneficial for both parties. It enabled us to identify gaps in our User Stories and streamline the application's complexity, resulting in a more intuitive design for the end user. Moreover, Figma's user-friendly interface facilitated collaboration, even with less tech-savvy individuals, enhancing our ability to refine the system further.

Now that we understand the app's user perspective more clearly let's delve into its underlying functionality.

Stage II: Architecture

While figuring out how users would interact with our system, we also looked at how different parts of our system would work together. Think of architecture as the blueprint, the plan for how all the pieces of our system fit and work together. It helps answer questions like how different things connect, what happens to stuff over time, and if one part is needed by another.

Our client knows a lot about tech, which helped in our discussions. Together, we made a picture of our system. We decided what parts our system needs and how they should work together. This helped us make our vision match the client's wants and deal with any tricky or confusing areas early on.

Even if we don't have a tech-savvy client, making a detailed system plan is still valid. It helps us spot any unclear or tricky parts before we start so we know what to work on.

Understanding how the system is designed inside was super important. Even though we didn't need to know every little detail, having the bigger picture was vital. Doing this work at the start saved us from giant problems later. We could focus on fixing current issues and knowing the basics of our system.

Now that our architecture was done and we knew what to do next, we needed to determine the cost of everything.

Stage 3: Estimation

Now that we've nailed down what our system needs to do and how it'll operate, it's time to tackle the financial aspect of things. With our plans and a clear project vision, the big question arises: what's the cost?

We've organized our User Stories and outlined our tech strategy so we can estimate the time required for each task. We're using a system that measures work time on "Mondays" – essentially, how many workdays each task will demand. While it's not an exact science, with a solid plan, we can come pretty close. However, life isn't always straightforward, so we need to consider uncertainties.

Enter "Risk." It measures our confidence levels in meeting deadlines using a percentage value. The less confident we are about a task, the higher the Risk. We arrive at our estimates by multiplying the risk percentage by the estimated time on Mondays provided by the developers.

Also, remember meetings: daily check-ins, reviews, retrospectives, and planning sessions. Though they seem relatively short individually, they add up over time. For instance, assuming 15 minutes for daily check-ins and 1 hour for each sprint for retrospectives, planning, and reviews, it amounts to over 5 hours per sprint per person. With five people onboard, it is over 25 hours a fortnight! For simplicity, we assume that around 15% of all project time will be spent in meetings.

Remember that estimating the cost isn't just about making a wild guess. It's based on our detailed plan and what we've learned from old projects and real work situations. If we know very little about a project, we might have to trust our gut more than facts, which could make our numbers less accurate.

But do we actually have to do everything?

Stage 4: Prioritisation

Now that we've locked in our estimates, we must examine our priorities and determine which features are crucial and which can wait for later. Sometimes, even the little things can make a big difference without breaking the bank.

When making these decisions, we're here to offer guidance, but ultimately, it's up to the client. They know their project best, so they get the final say.

To keep everything on track, we team up with our clients and use a handy tool called the MoSCoW scale. Each task is categorized as a "Must have," "Should have," "Could have," and "Won't have." This system helps us prioritize tasks for different project phases, ensuring the most important stuff gets done first.

With our estimates and priorities set, it's time to look ahead and start planning the timeline.

Stage 4: Gantt

The Gantt Chart marks the next stage in our planning journey. It is like a roadmap for our project, showing us what needs to be done and when. It takes all the details we've gathered about the project and puts them into a timeline everyone can understand.

However, figuring out how long the project will last can take time and effort. We must consider things like breaks, vacations, and sick days. Some tasks depend on others, so we can only do them in certain ways.

Knowing how many people are on our team is also really important. Although everyone helps, smaller teams can only do so much at a time. Understanding this helps us plan better.

The Gantt chart shows us when things need to be done, in what order they need to happen, and when team members can pitch in. Using it helps us determine the best way to do things and ensure we finish on time. It is a way to visualize the project's timeline, showing what will be ready, when it will be ready, and how many people will be needed in order to make it optimal.

We also use the "focus factor" to ensure our timeline is realistic. This considers how much work each person can do in a day on average. This will also account for days off. And because every project is different, we have to be ready to change our plans as we go along.

And... that's all!

Culmination

After spending over a month in workshops and carefully planning each project step, we've set clear goals, refined designs, estimated costs, and scheduled tasks. Using proven methods and working together in workshops, we've tackled uncertainties and stayed on track with our client's needs. These methods have helped us stick to our budget and timeline almost perfectly. While we know things could change, we're ready because we've laid a solid foundation and understand our client's needs. With this approach, we can handle whatever comes our way and deliver outstanding results. If you want to know more about our journey and how we succeeded, you can find more information here.