Any work that we are doing, even if it’s done by individual efforts, will affect others in some way. The affected other side is the end customer who is concerned about benefits and results from this work. The end customer can be a consumer, a citizen, an organization with complex teams, or even a collection of all.
I believe that working individually or within a team(s) needs a different mindset shift that can have more understanding, empathy, active listening, collaboration, and appreciation.
This kind of relationship should be from both sides, not only you as who is doing the work but you as who is receiving the end results of this work. We are always facing challenges while delivering and observing teams that are complaining about the customers and how tough they are, how the customers provide vague and unclear requirements, how the customers want to change their needs without paying costs, how the customers are not appreciating the efforts.
Many complaints, sometimes I actually feel the same, and I become very frustrated. In these situations, you need to pause, rethink again, emphasize, and see what is the outcome of this tension, what are the trade-offs we should take, and what are the implications of our actions in the long term relationship with that customer.
It is not always on the customer side, it is also inside the team who is carrying out the implementation, and this team’s understanding and how the team is showing empathy.
Many times, I see individual members of the team who are seeing the customer as ignorant, they do not understand, they are seeing themselves as the experts in the situation and the customer is outdated. Sometimes, team members quit the project, or a company does not want to work again with that customer because of how tough was the process and the relationship between the teams.
Changing the mindset is not something easy, it may need changing our way of analyzing, engaging, implementing, negotiating, contracting, and many aspects that can support the healthy relationship on both sides between the implementers and the customer for better end delivery.
So, I wanted to list different mindset shift factors that can affect the way we think from both sides to deliver better usable solutions. I am using the client to indicate the end-user(s) who will be involved to provide their needs and requirements, impacted by the change introduced by the solution, and concerned by the outcomes of this solution. The implementers who present the teams that are responsible for the implementation and delivery of the solution. These two sides can be in the same organization or two different organizations, below is the summary of these factors:
|Relationship||Client-Vendor relationship mindset||Partnership mindset||The expert mindset||The learner mindset|
|Listening||My way or the highway mindset||Listening to act, and take the right action||Execution Mindset||Understanding and empathy mindset|
|Needs||Everything is important mindset||Priorities Mindset||Solution boundaries mindset||limitless alternatives mindset|
|Scope||Unbounded scope mindset||Realistic and focused scope mindset||Rigid scope mindset||Adaptive & dynamic scope mindset|
|Management Framework||Project Management mindset||Product Management mindset||Scope management mindset||Expectations and Value management mindset|
|The Adoption Journey||Business needs as destination mindset||Operation needs and the journey mindset||Develop for test and deliver mindset||Develop for usage and operation mindset|
|Practices||Fixed mindset||Innovative mindset||Solution defensive mindset||Resourcefulness mindset|
In the next paragraphs, I will discuss each shift factor in detail.
To get a specific benefit, you need to do some effort to achieve that benefit. This effort means time, money, and resources. If you implemented that using internal resources or an external supplier, it is money in the end. If the relation between the client and the implementer(s) became a client-vendor relationship it will be very hard to make harmony between the teams. It will always create tension, the implementer will not try to give the best, will always stick to the scope, to avoid more tension. The implementer will not go the extra mile for a lack of appreciation.
If you are the client, it does not mean that you are always right. When the implementer is listening to your needs and challenges that you state and share, you have to listen to their concerns and their recommendations. You as a client contracted them for a reason, and there are no crystal clear requirements. Needs and requirements always evolve, and they cannot evolve without a partnership relationship.
On the contradictory side, The partnership relation will drive the implementer team to live your suffering, feel your fears and concerns, show understanding and empathy, share knowledge because they are the masters of the solution, and do more because they become part of the situation. This kind of partnership will not help you only as a client in today’s strategies but for the future as well.
From the implementor’s perspective, if you implemented the same delivered value of the solution before, it does not mean that you are superior and always the expert. Every project is unique, according to its context, new things will be introduced, you should wear the learner hat and understand more and put yourself in the client’s shoes.
And other times, you should be the expert and come up with bold decisions not to leave gray areas when there is a huge divergence in opinions and thoughts.
The partnership relationship will not only be limited to the current value that will be delivered in the scope, but it will last to other new benefits and values to be achieved. It is a responsibility for both teams to establish and maintain this kind of relation. Teams from both sides have to invest time in building strong interpersonal relationships and trust, which enable collective visioning, understanding, and learning.
This is very linked to the next shift factor “Listening”
Listening is one of the critical skills that improve the communication between teams which will affect the relationship. Unfortunately, most people listen to reply and not to understand. On both sides, listening should become more active-listening.
If you are the client, and the implementor is giving you advice, do not just listen to the information for just knowing. Try to rethink what that means, and how you can act based on this advice if it is applicable, and do not jump to a conclusion. It should not be always my way or the highway.
If you are the implementer, one of the expected behaviors is to communicate effectively, and you cannot do that without active listening and understanding the actual needs and pain, and renationalize the challenges the client is facing to actively give them a proper solution.
Most of the clients try to get most of the features and ensure that the target scope will cover all minor details before major functionalities. It is important to re-think why actually you as a client should consider this feature as an actual need, embed the why in everything, it does not mean that if it is something currently exist that it should be there in the solution. Sometimes, you need to reimagine how the solution will change the current normal to introduce new enhancement and eliminate existing wastes in the process and operations.
The client should be open to new things and new alternatives. The scope should be dynamic to make sure that the target value will be achieved. It is fundamental to think about what really matters, how to prioritize the required features. Not all features and needs are equal.
In one of the researches done by Standish Group, at the Third International Conference on Extreme Programming (XP2002), the Standish Group reported that 64% of features are never or rarely used in reality in typical software systems.
This is a huge percentage, imagine that you invested 1 Million dollars to build the solution, it means that there was a waste of 640 thousand dollars, this was a waste of resources, time, and money. This was the waste during the implementation, but this cost will extend the maintenance of these features as well at least 20% of the total cost every year. Can you calculate the waste?
You as a client should think about the 80-20 rule, in which 20% of the key features deliver 80% of the real value. Anything after 20% is actually a complementary or a nice to have feature.
From the other side, the implementers should address the needs and be dynamic for new changes. The implementers need to turn defensiveness actions of requirements changes into curiosity.
The Implementers should support the client in requirements prioritization, ensure the most valuable features and needs are delivered first, thinking about the needs that currently put the client under pressure. You should consult the customer and trade-off and deprioritize some of 80% percent of the complementary features.
It is not something easy in reality, and I’m not saying to accept alternatives and features substitutions that can cost you more. But, seek understanding before saying no to changes, imagine the value of the new needs, assess and discuss the impact, and show it transparently. Building on the partnership relation, it is a win-win situation, delivering what the customer actually needs with having adequate compensation. And in the same way, the client should understand the impact of the change on the time and cost of the project. This point will be covered more in the scope factor.
Most software engineering practices and frameworks when described have a strong analogy with Civil and building engineering. Which is a great method to describe software development, management, and architecture as something not tangible with the building of its process to build, manage the building project, and its architecture as something tangible that anyone can relate and understand.
The main issue is, the building is rigid, hard to evolve and expand, hard to change its space, landscape, layout, location, … etc. while the software applications nowadays are very dynamic, every day brings new changes and new needs. So, it is not fair to follow other improper frameworks that manage something rigid to be used with something dynamic.
It is essential to have the scope, but it should not be fixed, it should have a good tolerance for new changes and to be realistic and focus on what brings the value to achieve the final outcomes.
If you as implementers are implementing something that will not be applicable for usage afterward, it will be a waste of time and money to continue because it is only what is in the scope. Then it will be more beneficial to revisit and rescope. I know that may sound insane with the existing contractual agreements. But can you count how many projects failed due to stuck in scope management and concerns, how many days lost in negotiation to align with the written scope, or initiate a project change management process? how many developed features have never been used but they are developed because they are in the scope?
In the figure below from PULSE OF THE PROFESSION ® 2018 report by PMI, the first 5 factors of project failure are related to scope management.
The software project scope and its contractual obligations need major changes and full reimagination. I would imagine having the scope only to mention the required value and outcome with prioritization, inside that having mini scopes that align with the agile delivery, each iteration or sprint has its own scope that is applicable to change within the same time and budget.
Having another complementary scope, that we just put the rest of the rescheduled, unimportant, and parked features that the implementers with the client decided to deprioritize them from the implementation. Yes, it is harder to manage and it requires extra efforts from project managers but it provides more agility, it will need some upfront planning and architecture.
Software Development and Delivery is a service at the end, we should deal with it that way, plan and “pay as you go” model. The main challenge that some clients see upfront planning is a waste of time and shifts the delivery time, but it will happen anyway. So, the planning and design is a separate scope, each sprint is a different scope that delivers specific value, feature, or benefit that applicable to change and reprioritization.
It does not mean to have a time and material contract, because it does not guarantee a commitment sometime of the end outcome. But the flexibility that time and material offers, and the boundaries that fixed scope provides.
The management framework
One of the key things that I realized, over time, the software applications became outdated, features are not used, lack of solution adoption, and people start returning back to the old process and routine. It is mainly because the client is considering the solution under development as a time-bounded project. This leads to putting pressure on the client to have all needs and requirements in a time-bounded scope. After this scope is finished, it is followed with maintenance but rarely without someone on the client side who is owning this solution from the business and operational side and thinking about its evolution roadmap.
You as a client should start thinking about product management practice, seeing the delivered solution as a product inside your organization. If there are no new potential needs after finishing this solution. It means actually that this is not a core thing for your business, it is one of the supporting solutions.
For example, if you are in a health provider business, HR application is not a core business application. You can deal with it as a closed finished system that provides the basic needs of the business. While, something as a Hospital Information system, it should not be just a finished system implemented on time, on specifications, and just completed. It should evolve with your evolved business and the evolved technologies to drive more innovation to your business and empower your competitiveness.
So, you cannot envision and imagine all the detailed requirements and needs that you may need now and that you may need after one year. You should consider it as a product that can be delivered by many projects, each project is time-bounded to deliver specific needs and value. This will make it easier for you to rethink and prioritize the needs and better manage the scope.
This will require assigning business owners who act as product management, who have the vision of how this product will evolve over time.
From the implementers’ side. It is actually a mix of frameworks according to the company. The one which wins, is always what is written in the scope of work. Yes, it is fair that if you already agreed on a specific scope is to follow it. Unfortunately, this is not the reality for most software projects. Most of the time, the client does not actually know the needs, or is waiting for something to make the needs more clearer, or wants to visualize the software to better decide what is the next best thing to do.
So, I think you as an implementer should manage better the client expectation and manage what delivers value at the end. This will take us back to revisit how actually software development services are contracted, to support the rights of both sides. Not to overrun the effort and cost from the implementer side to just add additional value, and not to create tension and unused solutions that are tight only to the scope boundaries.
The Adoption Journey
Most of the time, when an organization wants to acquire or build a new solution, they consider only the business needs in terms of what the solution should do. This solution should provide this list of modules with this list of features, this list of qualities, and this list of roles who will use the system.
The solution is developed but it lacks usage and adoption because mainly they missed the operational needs which define how actually the system will be used daily in the organization. Even the User acceptance testing process usually does not cover that part, because when the client team is testing the solution, they are also testing the functionalities. They do not put themselves in the mindset of the actual user who will use the system day by day. So, when the user starts to actually see the system, he starts to raise concerns, for example, it takes time to enter the data, this feature is missing and I cannot do the work without it. Another concern about the user working environment, like connectivity, outdated desktops, old screens that do not support the system-defined resolution. Or new hybrid work models need, like remote and virtual work enablement.
All of these concerns are actually manageable by involving more actual users from the field in the testing process and do the testing from different locations, getting their feedback, and observing their day by day experience.
The main operational issue is, the new system may introduce new processes, but the organization does not change its internal processes to align with that change which makes the system not operationalized. Sometimes, it may need new job roles as well to exist inside the organization to perform one of the system roles. Without having that, the system operations cannot be done.
So, it is important from the client perspective to change the mindset to not only think about the features and requirements needs but also from operational needs.
On the other side of the implementers, the development and testing mindsets need to be changed. You should not only develop the features to run and just perform what it is supposed to do, you should care in the process starting from designing until delivering how the developed features are used and how they can provide a better human experience. I hope that we will have automated AI testing that simulates the end-user behavior during the testing that can capture the actual pain that end-users may face while doing the same job on the system daily. And how a system can enable the user to outperform and not become an obstacle for him.
This will need a huge effort from the user experience team to develop a better human experience for the end-users, making the user interface handy and easy for them to understand.
Usually, most organizations when they start developing new software, they are trying to design the software based on their current practices and existing experience to become digital, ignoring that digital is actually meant to change the current practices and innovate.
So, as a client, you should think about what needs to be changed in the current practices with an innovative mindset. You should ask about the implications of the solutions on the organization’s capabilities from people, processes, and other existing technologies. You should not rely only on what are the best practices. Best practices were good at another problem and solution context at that time but does not mean that it will be best for you. So, I believe there is nothing that is called best practices in the absolute and just following the best practices without innovation can lead you to a new outdated situation.
For example, having one-stop services delivery centers for citizens, where the citizen can go and take all services from just one location and one window, which is one of the best practices in government since the early twentieth century. It is still good and valid but with innovation, you can come up with a fully digital virtual center and avoid building centers and eliminate waste of time for citizens to visit the services center.
On the implementers’ side, you shouldn’t just think about your solution boundaries and its delivered features, with every project you are doing there is a new need that can stimulate more innovative ideas that the implementation team can learn from. So, be resourceful to share ideas, knowledge, and experience. Do not limit yourself with the scope and solution boundaries, focus on what delivers value.
If you are a client or you are the one who implements the client’s needs, start applying these mindset shifts. Let me know what do you think of these mindset changes? Do you have any to add?
Also published on Medium.