Customer & Service Provider interface … the End of the Story
With the start of the-then-new job in October 2015 I started writing about my experience – and especially the shortfalls – in our customer and service provider relationship. It turned out to become a triptych. This is the final – the wrap-up.
To catch up you might want to read the first post: “Customer & Service Provider – Epic fails” and the second in this series: “Customer & Service Provider – silver lining on the horizon“.
You might ask yourself … why is that the end of the story? Improvements in processes usually don’t have an end. Well, let’s see.
The Modified Setting
In the meantime we upgraded from 2,5 software developer to even 3,5 software developers. Ambition behind is …
You might guess it? …
Come on …
YES! Right – on the first attempt.
Speed up the delivery of features. Our senior management is delighted by the achievements so far – however is far from being satisfied with the results, the outcome. Still, there is great belief that more people build more results. True! BUT we’re still having the issue of not well-defined requirements and still having long periods of wait for answers from our business leads.
On a daily basis we’re still in communication mode. Twice a week our project manager and the project manager of the service provider meet to exchange progress and start discussion on new topics. Again, communication proves to be a gold nugget!
The Now Situation
Missing product management – It became so obvious, so non-neglectable, so crystal-clear. Reason behind the low througput of our development cycle is not the lack of software developers – that’s a symptomatic solution. No, root cause is: we’re lacking a professional approach to manage our products – product management is missing. Usually, product management’s major duty is to define requirements on their products and harmonize the various needs and demands from all involved parties – customer, departments, management.
If we just had some people doing exactly this job. World would be much clearer!
- Prioritization would be easier – since the product management would clearly include management in the overall prioritization process.
- Definition of requirements would be clearer – only well-defined stories were handed over to our service provider.
- Decision points would be clearer – product management is the definition point for detailed questions and processes.
- Communication would be simpler – it’s simply clear whom to ask for guidance.
- Development would be faster – no impediments any more … why should it be slow now?
In my last post, I raised a lot of points:
- Multiple stakeholders talking to the service provider
- No clear communication of priorities, requirements and goals
- Fundamental changes in design after going live
- Bad requirement quality
- Silo thinking
- Low quality – not well thought-out
- No consistent prioritization
All of them – I really believe – all of them could be solved with the implementation of an organizational change – introduce product management.
So, you might ask yourself why is this the end of the story? Well, that’s an easy one. Despite my continued effort to convince my senior management about the absolute need to improve the organization by introducing a product management person (yes, one person!), I failed. “Too expensive”. I personally decided to quit.
Lesson learned?
I’m still convinced we changed a lot for the good in the customer / service provider interface. Agile patterns did a great difference for all of us. Furthermore, the service provider did invest in agile coaching (and architecture consultancy as well … not all is gold …) and showed great willingness to cooperate – to improve.
Go on, improve your interface. It’s well worth the effort! Ah, and don’t forget to secure your senior management’s backing in early stages 🙂