Imagine that:

You are in a meeting with your team where a new feature is being proposed of being implemented. You listen to the things they are trying to do and something does not feel right. You try to raise your hand and express your opinion. Your raised hand is seen and and you say:

“I see what you are trying to do, but I am concerned that the technical pre-requisites are not met. If the solution cannot integrate with our IAG solution or at the very minimum active directory, it will be an app to be manually managed which means there is extra pressure on us to keep this going.”
A valid concern.
It is dismissed that the solution being implemented is just a POC and in the VIP stages of the solution they will look at integrating the features you said.
In the end, you do not really feel heard as your concerns are dismissed and there is no plan given for when it does not happen who would in the end be responsible.

 

When reading the above story there is multiple things that can go through your head:
  • “They should have used the meeting to create a RACI, then it is clear who is accountable”
  • “The project should have a clear plan defined over the next 3 years where it is explicitly mentioned when those features are implemented”
  • “The product owner should have blocked this request, and listened to his team their concerns.”
  • “Why were we not involved from the beginning when this solution was being onboarded? We could have given the feedback to begin with instead of doing this over and over again at the implementation phase.”

 

All of the above things are valid opinions to have. And in some organizations, they might even be so valid that you could even implement some of the above suggestions. There is just so many things happening in an organization where processes are being blindly followed as this is the learned behavior that has developed over the years.

    Because let’s be honest:

    • Do you really think a RACI matrix would have solved this issue? You would have something on paper but in the end when the project loses their budget or is poorly implemented, you are still stuck with the implemented solution.
    • The project could have the best possible plan written out, but the reality is that in an enterprise context a lot of things shift all the time. Suddenly the project an out of budget, an architect has left, and the project is postponed, the project is a pre-requisite from another project and “you just need to push through”. There are so many things that can happen in 3 years, and even though having a  plan is a good idea, the time and energy needed to have maintenance on that plan is a huge cost.
    • The PO could have blocked the incoming request which could have been a temporary step, but will most likely be overruled by someone who has higher authority.
    • If you are being involved in each and every project, this might be good for blocking these types of request, but what about the core services that you give?

    As we are being honest, their is no: “One solution fits all”. What does exist is someone who can advocate the best way forward for your organisation during each of these steps. Every single item in this story is a separate issue.

    u

    The raci matrix is being suggested as their is a lack of accountability EXPECTED. It is always good to have documentation you can refer to, because we cannot remember always and everything. But you should ask yourself the reason: why do we have it? Why are we doing this? Is there an underlying issue we need to solve?

    u

    Plans are great in letting us feel good. It shows a positive way forward and defined and set goals we can meet. It is the length here that is the issue. Nothing wrong in having a high level view of where you would like to be, but the detailed plan should be a maximum of 3 months. You never know what happens. Imagine something happens during those 3 months, do you stick to the plan or shift based on your new findings?

    u

    If a PO does not block this request, I use something which is called API. No it is not an API like most developers know, but rather “Assume Positive Intent”. The PO might have extra reasons why they cannot deny this request. It might be the PO has more knowledge that he has not shared yet. The PO might listen to the concerns but is personally being pushed to implement the solution. Whatever the reason is, there should be a psychological safe environment where both team members and the PO are able to converse this safely. Even better would be if the psychological safe environment is cross the organisation and giving negative feedback like this is even encouraged. (This you will find in much later stages of implementing Agile)

    u

    Having to be involved in each and every project sounds like a process nightmare to me. All solutions start from an acquesition. This mostly goes through procurement. How come procurement does not have a list of pre-requisites before accepting an application? Instead of managing dependencies, you solve the root cause issue at the source.

    And do not get me wrong, writing this down is way easier than implementing the solution at hand. There will be many meeting where you will express your concerns. It is important that all sides of the story is heard and you can collaborate to the best possible solution.

    Envourge your people to speak, contact us now