How to successfully run your software projects without any delays? 

Magda is the project manager with a knack for some UX/UI design. She’s had a chance to work with many of our clients as well as participating in the creation of our website, which made her well-acquainted with the world of eMobility.

Magdalena Betlińska

A firm understanding of a project’s requirements and scope is vital to the success of any project. This knowledge is used to determine what the final product will look like, what work will be required to achieve your goals, and provide you with a rough timeline. It also gives you the tools you need to adapt to changing requirements or circumstances more easily and keep your project on track and on time.

 running smoothly, the SolidStudio team has developed a robust yet flexible process that is easily adapted to suit each client’s unique needs. Regardless of 

 is here to turn your idea into a reality.

Before we get started, we sort clients into two broad categories: those who already have a scope prepared and planned and those who are still determining their scope. In this article, we will focus on the latter.

As we lay out the initial specifications, we determine the functional and non-functional requirements. Functional requirements cover areas such as business behavior, while non-functional requirements cover areas such as how many users can (and likely will) access the system at any one time and whether or not the product needs to be available to users all the time or only occasionally or at specific times. This process involves sitting down with potential clients to ensure that everyone is starting on the same page.

Not all clients know exactly what their project requirements are when they first sit down with our team. If a potential client is unsure about the exact requirements of their project, we will run a 

 for them to help everyone gain a better understanding of their project’s needs. Each workshop typically takes between 2 and 4 hours and gives our team the chance to work closely with the client and allow us to create an actionable vision for their project.

Once we have a basic understanding of the project, we will meet as needed with the client to discuss features, priorities, delivery dates, and what will occur during each phase of the project.

Once the details have been determined, we will create a high-level estimate covering each feature and epic. It is at this point that the compensation discussion and starting date are also finalized so that work can begin.

All of our plans and estimates are built on a solid foundation of experience and expertise. While some standard features such as authentication, user self-management, and creating CI/CD pipelines have a standard scope that can be applied to all projects, all unique features of each project are custom scoped. This ensures that work is never rushed, and corners are never cut to satisfy deadlines, budgets, or other external requirements.

We believe in bringing value to our clients and potential clients, which is why we work closely with our software developers, UX developers, and product owners throughout the entire planning and creation process. This helps us identify areas that need more attention to add value to the overall project, allowing us to adjust project requirements as needed so that the final project is the best it can be.

Challenges & Pitfalls: Overcoming Obstacles

As with any project, things don’t always go smoothly. One of the biggest challenges we face is staying agile and flexible so that we can quickly and effectively adapt to scope changes or changes in the wider market. We overcome this challenge by keeping our clients in the loop throughout the entire development process so that the client is never caught unaware if the scope has to change.

We also work hard to lay a solid foundation for any project we take on. We have found that investing in the planning phase, through discovery workshops, proofs of concept, and detailed UX design, helps yield better results and minimize challenges and other disruptions. Laying a solid foundation also allows us to provide clients with better estimates and helps ensure that our team and the client are always on the same page.

One project that benefited greatly from our flexible and methodical process was 

. We worked with the T-Cup team to create a minimum viable product for their web-based application that helped users track and improve their wellbeing while ensuring strict data privacy. We supported T-Cup throughout the entire process, from the planning and workshopping phase to backlog development, implementation, hosting, and support.

For more information about this case study, please visit 

Event storming is worth a shot and here is few reasons why.

Having a chance to work with well-established startups from the e-mobility sector, Bartek gained invaluable knowledge on the industry requirements. On his path, he was given the opportunity to work on numerous EMSP applications and CPO platforms. Bartek is also our Head of Delivery.

Bartłomiej Łazarczyk

Most developers already had the chance to hear or read about Domain-Driven Design. Long story short, this approach is meant to help in modeling complex domains by offering precise tools and encouraging the use of specific, domain-oriented ways of thinking. It is a powerful methodology that works perfectly well with greenfield projects. But what about a legacy system that was, in addition, poorly designed and maintained? The cost of introducing this approach to the entire company is huge, takes a lot of time, and requires some training courses (not only for developers). Thankfully, there is a simple technique invented by Alberto Brandolini called 

. This is a good starting point for discovering Domain and introducing DDD.

Recently, we have started to implement the Domain-Driven approach together with one of our clients, and our goal is to integrate processes for discovering domains based on different Event Storming workshop variants. In the wake of a few sessions completed so far, we have reached some insights, and we would like to share some of them in this article.

First, let's focus on the workshop itself and its most popular variant, Big Picture Event Storming, with its basics and how to facilitate it. The main goal of this workshop is to gather all people that have a business, domain, or technical knowledge in one place and model the current understanding of the system.

You might say that there is nothing special about it, right? There are many other workshops and techniques that accomplish the same, so what makes Event Storming special?

The biggest advantage that speaks in favor of Event Storming is the clear, easy, and structured way of communication between employees from different company units. And because of that, we can naturally stimulate our participants to start a dialog, discussion, share thoughts and, most importantly, to agree on the language and discover it with us.

To perform this workshop and make it successful, you need three key ingredients:

The right people - a greater variety of the group, may color the final view by reducing bias, but be sure to invite only those people who have the most influence or knowledge about a given subject and care about the problem. They will be your domain experts. Developers with long service can be useful experts too, but they need to understand that the event should be considered as business-related.

A good location - the room needs to have at least one long wall and be large enough to accommodate gathered people and give them some space.

An experienced facilitator - you need a person or two who will ask the right questions, timebox every phase, and be able to explain all the rules and stages clearly so everyone would understand them.

As I wrote before, the room needs to have a long, straight wall on which you will be able to stick paper rolls. The bigger the wall, the better. At least at the beginning, all the participants should have space to stand and walk, so you also need to move all the seats to the place or corner, which is not easily accessible. The next important thing is a table with a lot of sticky cards in different colors, a few markers and a board with a legend of what each card means.

Sticky cards are the best tool used in the meeting. In the Big Picture variant, we can differentiate between five types of cards.

Orange cards represent an event and are the main building blocks in our process. To be more precise, this is an event relevant from the domain expert perspective. Events should always be phrased at past tense. Example: Report was generated, Charging has stopped.

The yellow card represents people involved in some event or process. You can treat it as an actor as well. Remember that the goal is not to specify people for each event but to accentuate the involvement of someone outside of the system. Example: Portal user, Support team member

The violet card represents the system involved in some event or process. It can be either an external or internal system. The same as in the card for people, the clue here is to emphasize some external involvement. Example: Third party API, Database

The red card represents a hotspot. This is used for marking a place with the lack of proper knowledge, something that is not working well or to mark a place of disagreement between participants. This is a sign that we need to take a deeper look into it later. Example: Generating report takes to long

The green card represents an opportunity. It can be used for specifying something that is already working quite well, something that we can improve, or some other handy ideas. It can be a good alternative to the hotspot card for an attendee who prefers resolving problems rather than complaining. Example: Delivery reception can be automatized

Up to this point, we have a place to organize the workshop, we have the tools - but what is the process itself? To quickly answer this question, there are five different phases in this meeting:

To benefit from our long, carefully prepared paper board, we need to draw a small timeline at the top of it, explain what each card means, ask everyone to think about some events happening in the system, write down an event on the orange card, try to stick it somewhere on the timeline and do it again and again until everyone runs out of ideas. It’s easy as that! Nevertheless, we often run into a problem with starting to stick cards. In that case, you need to encourage everyone or place an example card yourself to show that it’s just placing a card on the board, nothing more. Since it’s chaotic exploration, the location on the timeline does not have to be 100% accurate but will be helpful during cleanup. This phase should not take long; if you see that no one is writing anything on the cards for more than a few minutes, you can just finish this phase. In the end, it should look more or less like on the image below.

After chaotic exploration, of course, we need to do some cleanup and sort out all the events we have gathered on the board. Unfortunately, it’s not as easy as it sounds. Some parallel processes will surely come up, people will try to kick all events around, and a lot of confusion will happen. To make this phase nice and effective, we can introduce some structure at the beginning. There are quite a few good strategies, but we highly recommend specifying a few pivotal events and introducing swimlanes. We ask our domain experts to choose up to four-five most significant events in the flow. They don’t have to be perfect; it’s enough if the other sequence of events is depending on some pivotal event and cannot happen without its occurrence. That will create a framework on the board, which makes sorting other events easier by determining whether they happen before or after a given pivotal event. We can introduce swimlanes for all sequences of events that can occur at the same time. When everything is put in order, it’s good to make a walkthrough from the first card to the last and assure everyone that they did a great job.

In this phase, we ask our domain experts to specify a few people and systems which play some role in the events. We need this information to have a full picture of the serious dependencies in the given system. It may also point to a place where there is no full control in the system, or where constraints and conditions are present.

So far, we have quite gained a lot of data about our domain, but still, it doesn’t feel as solid and detailed as it should be. To encourage our participants to be more creative and take a different perspective, we should spend more time on the backward walkthrough phase. In general, we need to ask someone from the audience to read out loud all the events starting from the last card. What is different now is that we ask additional questions like:

Is there something more happening between X and Y?

These questions will make domain experts think in different ways, stay focused, and not take something for granted. As a result, we will have new information and more details - and therefore, new events, new flows, and new structures. The most important rule here is to discuss and fill the magic gaps between events if they are apparent. There might be a situation when an agreement cannot be made due to a lack of knowledge. In that case, marking it as a hotspot is a good choice.

The last phase could be optional, but the overall picture of the system will gain a lot from that information. We would like our domain experts to specify hotspots - aspects to improve, and opportunities - ideas to introduce. After that, we organize short voting by drawing an arrow near the most important hotspot/opportunity in the system. This information is a very important sign that in any further discussion, we need to dig deeper into this area and try to solve this problem. We can also prepare a simple metric for a given hotspot/opportunity so it can be expressed with numbers, and as we know from our experience, numbers are intrinsic for business.

As you have already seen, this workshop is not so complicated from a technical perspective and probably could be performed by anyone who knows its rules. However, just as in real life, details play the biggest role. Some obvious behaviours and attitudes are often forgotten in effect, so here are a few tips that came along with practice.

Event Storming is all about the people and their knowledge. The goal is to have as diverse and useful a group as possible. To achieve that, a simple stakeholder mapping technique comes in handy. We need to find a person who knows the system and the company quite well. It can be a Product Owner or someone from the management board. Then, together, try to determine potential participants on a simple figure with two axes: influence and interest. For simplicity's sake, we can divide the figure like in the image below and map people into those areas. The conclusions are self-imposed.

Remember to make the goal of the workshop clear to everyone, especially in the Big Picture variant. People often tend to lose their track if they don't narrow the scope a little by having an explicit reason for carrying out the workshop. That may result in many wrong, or irrelevant events, so unnecessary confusion could happen by accident in further phases.

A good facilitator is priceless and makes a huge difference during the workshop. Leading a workshop is a skill that demands time and experience to be improved, but fortunately, we have some advice on that matter (especially useful if you're just getting started).

At first, keep the meeting and rules in scheduled bounds and don't allow too much freestyle. Boundaries trigger creativity and require mental effort. The next thing is about too specific questions during the Big Picture Event Storming. Not everything is important and necessary at this level of abstraction. More details should be discovered later when the scope is limited, and we have a clear goal to deliberate specific aspects. When something is not clear, just mark it a hotspot.

The last and most important thing is to focus on the language that springs out during the discussion. Domain-Driven Design puts linguistic differences first, so try to pick up details and attributes up as much as you can. Ubiquitous language is necessary to appoint subdomains, and there is no time to write down everything that has been said.

If you gather people from different company units, they could have their own definition of an event. It is really important to have a common understanding that events should be relevant from a domain expert and from a business perspective. An event should not be connected to some implementation and technical concepts because it's highly probable that it doesn't reflect the problem and domain. Often, it is far and away from the business-related issue, especially when you are considering a legacy system that wasn't designed in a Domain Driven way.

Do your best to specify good pivotal items. Ask as many detailed questions about chosen events as you can, e.g., "Are there some events that cannot happen if this event has not occurred?", "Is it necessary for some processes to start and go on?", etc.

This will speed up the cleanup phase, and in the future, it can point to a moment when the language is changing. Pivotal events often come with new processes that could be related to different subdomains.

It's hard to book at least three hours in everyone's calendar. It's even harder to stay focused and feel good during such a long meeting. Proper timeboxing and breaks are a must. Spend your time, more or less, in these proportions:

Chaotic exploration: about 10-20% of time

Enforcing the timeline: about 30-40% of the time (cleanup takes some time)

Backward walkthrough: 30-40% of the time (most of the details come up here)

Hotspots and Opportunities: max 5-10% of time

People would love to see the result of spending their precious time on discovering their domain. Also, from the perspective of a software architect, you need to have a better overall view and possibility to manage it without effort. Digitizing it seems to be the best solution, and for that, we recommend an online tool called Miro. It has a feature to capture sticky cards and convert them to online notes, which can save a lot of time.

Now that we have finished the workshop, everyone is completely exhausted but also satisfied with what they have achieved. And then they ask the important question: What is going to happen next?

The answer is simple. Now it's time for the domain architect to discover and validate the subdomains. We have a big picture view of the whole system, but we don't understand it yet, we cannot tell what exactly is happening underneath, what problems there are, and what exactly we want to solve.

We need to determine emerging subdomains. It's not easy; some even say it has more in common with art and intuition rather than logical patterns and equations. What's more, there are dozens of heuristics and techniques for doing it, and none of them are universal.

Nevertheless, here are a few worth mentioning.

This can be a good entry point for further considerations. Each organization has different units that can reflect different subdomains. Unfortunately, business processes, which are a part of the core domain, often cross different departments, so we cannot rely on this heuristic much.

It's a common situation that within one company unit, there are few domain experts responsible for different issues. This is a clear sign that we may expect different problems in one place and may need different subdomains.

Probably the most important and practical heuristic, which assumes that words and terms have a different meaning in different contexts and subdomains. Company products have different meanings in the sales department and different meanings in the warehouse department. If we don't focus on the language, we risk failing to see these various perspectives, life cycles, and issues separation.

If some aspect comes with huge business value, it should probably be a separate subdomain. You can be almost pretty sure that this aspect is connected with the core domain, the company determinant.

Many business processes often involve different subdomains. Establishing factors that highly influence the process may point to a change of involved subdomain. Finding that might require introducing a clear chronology and asking for more details about what is happening between two events.

Discovering complex domain with Event Storming

Still afraid of missing your deadlines? Read this piece of content and find out way to avoid it.

After founding Solidstudio, Pawel was an originator in terms of pursuing expertise in eMobility. With the build-up of a solid knowledge-base on industry’s needs & wants, he now keeps a close eye on products’ development. He’s also hugely responsible for the business’ side and designs the business models for our products.

Paweł Małkowiak

Project delays are frustrating and can end up costing your organization more than just time. Depending on the nature of the delay, the direct and indirect costs to fix it could be substantial. Direct costs such as re-doing work or requiring more work than originally planned and indirect costs, such as having to pull workers from other projects or tasks and delaying those items as a result can add up quickly.

Fortunately, you can take steps to minimize or even completely avoid project delays and keep your project humming along smoothly.

Common Project Delays & Their Root Causes

Planning is one of the most critical stages of any project. When teams don’t spend enough time planning and figure out exactly what the project requires so that it can be 

Without a solid yet flexible plan in place, some features can end up taking more time and energy than expected or may require more functionalities than you have accounted for. You should also make sure you have a plan in place to ensure each component can successfully integrate with the whole project. Trying to make different components work well together can eat up a lot of extra time and energy, and can compromise the integrity of the whole project if they aren’t properly taken into account.

In too many cases, teams don’t fully recognize their project’s requirements before they begin development. If you don’t invest enough time and energy into the planning phase, you may encounter portions of the project you haven’t planned or budgeted for and may end up scrambling to finish the project before the deadline.

This issue typically arises when 2 or more companies work together to complete a project. For example, if one team is responsible for UX design and another handles the development side you need to make sure both teams are on the same page at all times, and that both are meeting their deadlines. A delay on the development side not only threatens the pace of work for that team but also for the UX team that is relying on them. This single delay ends up delaying work for both teams, potentially delaying the project even further.

Not Having the Right Skills for the Task at Hand

While a screwdriver is great for working with screws, it is a terrible substitute for a hammer. When 

 or building an internal team of developers, you need to make sure you choose people who have the right skills for the job.

Far too frequently, we encounter companies that have committed to a project and realized after the fact that their team doesn’t have the necessary experience with a particular domain or technology that the project requires. While this obstacle can be overcome either by hiring additional team members, 

outsourcing part or all of your project to a more qualified company

, or training existing team members, all of these solutions require extra time and effort to implement, threatening the project’s scoped timeline.

How to Minimize (or Even Avoid) Project Delays

Have a Plan That is Both Detailed & Flexible

As we discussed previously, investing in the planning phase is crucial: a good plan sets your project and your team up for success while a poor plan or a vague plan sets you up for failure. That being said, sometimes unexpected issues arise that will require you to adjust your plan, so make sure that the plan, and the scope, are both flexible enough to accommodate unforeseen problems.

All key team members should be communicating with each other daily.

 This helps ensure that any hiccups or obstacles that arise are communicated effectively to the rest of the team so they can create a contingency plan and react accordingly. Regular communication also helps avoid miscommunication, which can delay or even derail a project.

You should always do your homework before partnering with any 

. Make sure you meet the individuals you will be working with and verify that they have the time and the skill set to complete the task. Meeting with your partner team also lets you gauge how they approach their work: Do they act proactively or wait for disaster to strike? Do they approach their job with enthusiasm or with a begrudging attitude? Do they appear rushed or stressed like they are stretched too thin, or do they appear competent and in control of their workflow?

The answers to these questions will help you determine whether or not a team or individual is someone you can rely on to get the task done correctly and on time. You should also make sure to pick a partner that can scale effectively to buffer themselves against challenges and delays quickly and effectively so that the project can still be delivered on time. This is where good communication comes in again: When the software development company and the client communicate effectively with one another, potential delays and other pitfalls can be spotted ahead of time so they can be avoided or addressed proactively instead of forcing team members into a reactive situation.

Overengineering, (where a product is designed to be more robust than necessary or have more features than are actually required, resulting in a creative process that is inefficient or unnecessary complex), is a common cause of project delays. To help your team avoid the overengineering trap, please read or blog post 

One good example of avoiding project delays is discussed in our 

Our team was tasked with migrating a legacy application to a microservice architecture when we discovered additional deliverables. To ensure the project wasn’t delayed, we scaled up quickly, adding 2 more developers to our original team of 3. We also invested heavily in building proper CI/CD pipelines. By investing the extra time and effort early on and scaling our team appropriately, we were able to save more time and energy later on in the development phase, setting our future selves up for success and reducing the amount of work required overall.

Sometimes even the best-laid plans can’t prevent delays. If a delay occurs, the most important thing you can do is approach the situation proactively and focus on finding a solution rather than assigning blame.

Understanding Project Delays: Why They Happen & How to Avoid Them

5 main factors to consider when choosing a technology partner

Choosing a technology partner: 5 main factors to consider

A skilled technology partner is essential for bringing digital ideas to life. But when it comes to identifying the best technical services for your business needs, where do you start?

Picking the right partnerships can be tricky, and there are a number of factors that require careful consideration. But the aim overall is to find a team of developers who can not only deliver the technical specifications of your digital product, but the necessary support to give it the best possible chance of success.

Choosing a technology partner is not a decision to rush into – it really can be the difference between success and failure. To help steer you in the right direction, here are five important factors to consider when choosing a tech team to work with.

It goes without saying that any technology partner needs to consist of skilled professionals. But what separates great development teams from good ones is that the former fully understands their chosen profession is a highly complex one, which can easily be misunderstood. A quality technology partner will make you feel at ease from the beginning, and be extremely forthcoming with crystal clear advice and guidance to help steer your project in the right direction. This should include helping you identify the best business model, analysis of the market and reliable, honest feedback on how viable your product and its chance of success really is.

Take a minute to look at who makes up the team of any prospective technology partners, and be sure to ask questions about their experience and skills. For example, how big is the team? What are their skills? What do they specialise in? Ensuring the development team you choose has the skillset to see your project through from start to finish is vital.

It can be difficult to gauge what people are going to be like to work in the beginning, but initial meetings should give you a good early indication of the way the team works. And a good failsafe for checking how relevant a company is to look for what services they offer and any achievements in cutting-edge technology like FinTech, Blockchain, Cloud, Saas and AI.

As mentioned above, whichever technology partner you choose should be able to offer expertise and advice at every stage of product development. A great way to notice if there might be any gaps in your pipeline is to take a close look at the services offered, and make sure they fit your business needs. If a development company is offering a variety of services, your custom is almost certainly in good hands.

 , we offer a wealth of talent and expertise, with full-stack services in the areas of:

 - IT solutions should match industry demand, as well as specific organizational objectives, which is why this early discovery stage is so valuable. It’s at this point that a product’s viability is researched and the market analyzed thoroughly before the best software solution is identified.

 - Individual projects have individual needs, which is why a company with the skill to develop custom software is invaluable – it’s the best way of ensuring a software solution fits the business requirements perfectly.

 - Developing a digital product is a complex process. In order to do so successfully, you need an experienced technology partner to support you at every step of the way – from needs analysis and prototyping, through design and development, to launch and ongoing maintenance.

 - If ever there was a time to embrace digital change, it’s now. Integrating technology into your business is a worthy investment if you want to help drive your business forward. A quality technology partner can help you identify areas of your business that would benefit from digital transformation, and offer the expertise to deliver the best possible software solutions.

 - The cloud's rapid rise in popularity means that it now exists in every area of IT. Cloud providers give us the opportunity to use multiple tools and mechanisms that can speed up the delivery process and give users a working product as soon as possible. Hosting an application in the cloud can also reduce operational costs, give an edge over competitors and allow instant scalability.

As a cloud application development company, all of SolidStudio’s products are hosted in different providers such as 

 , Heroku and Google Cloud. We utilize these providers to the maximum and build applications with a fantastic infrastructure, completely tailored to your needs.

 - Financial technology is no longer just about supporting established financial institutions, it applies to any innovation in how people transact business. SolidStudio is a FinTech company, and are very aware that no company can afford financial or reputational losses, which is why we build our solutions to ensure your safety with the highest standards, quality and processes.

 - As technology changes, so does the way society interacts. More and more companies are looking for ways to reduce operational costs - cloud solutions are increasingly being adopted and their value cannot be underestimated. As a serverless development company, here at SolidStudio we can build a simple, scalable API or a data processing platform, with minimum configuration alongside automatic scaling and a pay-per-usage format.

 - Software as a Service (SaaS) is a term you are no doubt hear more and more these days. As businesses begin to realize the benefits of cloud-based software for streamlining and optimizing operations, Saas has become a very popular solution for many. SaaS provides organizations with significant advantages that make it one of the most sought-after software products today. At Solidstudio, we support companies in developing SaaS applications that are flexible, scalable, and provide all the features our clients need to achieve their business goals.

No matter what your level of digital expertise, whichever company you decide to partner with should be open and honest from start to finish, providing explanations and reports that are both easy to understand and completely transparent. Trust in business is key, as is ensuring both parties are on the same page about product requirements, costs and goals.

The pre-development stage is key when it comes to transparency. A good technology partner will allow its clients access to every report and any project management tools related to the project at this time. If that’s not available, even on request, it would be worth looking at other services elsewhere.

The ideal scenario is to pick a development team that can inject as much passion into an idea as you. After all, they will be working on it too, right? If your partners take ownership of your product, they are far more likely to go the extra mile when it comes to delivering the best possible solution within the specified timeline and budget.

But that should absolutely not compromise on quality. Every good development team fully understands the importance of quality and wants to deliver the best possible result. And that will require planning and quality control, including a clearly defined strategy and testing to ensure the right result.

Leaving your most precious ideas in the hands of strangers is an understandably daunting prospect. But it’s the job of a good technology partner to leave you feeling safe in the knowledge that they will not only help you bring these ideas to life but also be very present after they have been realized. At initial meetings, be sure to ask how they will support you in terms of maintenance, promotion, scalability, analytics, and any technical issues that might arise after launch.

A good technology partner will make sure you’re not going it alone, with services that include support before, during, and after a product launch.

After all the information in this article, you should now be able to confidently approach prospective technology partners with your ideas and questions on how they can help you make your digital dreams become a reality. Good development companies won’t hesitate to answer your queries and will do their best to help find clever business solutions, be loyal to your brand and assist you with ways to scale your business in this ever-evolving digital age. You will undoubtedly encounter different levels of technical complexity as your product evolves, so you need a competent, skilled team on hand to help with any eventuality.

If you need any further information on how our services can be of assistance or more information on how to choose the right technology partner for you, please contact us here.

Five important factors to consider when choosing a tech team to work with.

A High-Level Guide to Understanding Your Project Requirements & Scope

11 AUGUST 2020 • 7 MIN READ