If you are working with a technology partner for a disruptive mission , read on!
We have all have attended a dozen presentations which start with how Uber, AirBnB are disrupting the traditional businesses. Honestly, I get rather put off if I see these slides in the beginning now. It’s a reality. We need no more proof! Almost all business have started to integrate IT into their core business (in a scale that works well in their organization). If you are part of an ambitious organization it’s very likely that your organization has one or more technology partners working along with your technology team to achieve your next goal. If you are managing any of these technology partnership in capacity of a sponsor, you might find the article worthy of a read. Most partnerships start with high expectations from both end, the journey however isn’t always very sweet.
There are few hygiene which you should check even before your IT partner walks in — 1) You are well invested in your organization and understand the reason why disruption is needed. 2) You have decent clarity on outcome of the project. 3) You have access to end users opinions 4) You have right skill set with you to work for the success of the project 5) You understand importance of roles and processes (so that you can question things which are not working well for you, while appreciate things which will enable to build great software) 6) You can take the final call on the scope
If you are a sponsor of a critical project and have been working with the technology partner below is a cheat list of things which probably can be easily missed but very important for success of your tech objective.
Participation and involvement is viral. Spread it!
If you feel you have hired best consultants and move out of sponsorship of the program then you might be at fault. You can not expect someone else to steer through your organization, drive innovation at work, do things accurately, achieve business value while you are out of sight. Your involvement and passion is viral! and there is no replacement. Talk to your partner about what you are set to achieve and infuse your passion in them.
It’s hard for motivated folks to fail. At-least motivated folks do give their best try. People want to be part of mission which is purpose led. Your involvement is enough for them to understand the importance and drive a closer to your dream.
You have to look out for audience to spread your passion. At times you may choose to talk to management team of your technology partner but do try to talk to the whole team once, you might be pleasantly surprised what you hear from youngest developer in the team! If time isn’t a biggest constraint, then it’s best to address the team as a whole and help them strive towards your vision. Your communication with your partner should involve metrics though should not belimited to that. You have to sketch out what is the vision of your organization, what is the program set to achieve, how will you measure success post release, how would you gather user feedback. Most of the folks in team get a creative kick by knowing what they are going to build will create a positive effect in someone’s life.
Talk to a developer, quality analyst, a junior analyst from your tech team and see if they understand what they are building. If you find a major gap in the understanding, you probably know that you have folks who are developing something that they do not know enough about. This is one of the biggest reason why your product might fail. Developing software isn’t brain dead activity, there is a constant need to innovate. If your tech team is unable to appreciate your problem it’s very likely that their innovations would also be limited. Ask your technology partner about ideas in which they can improve the program, their replies might be able to give your hint IF they are doing a 9–5 job OR IF they think of constantly improving.
If your mission is disruptive and critical, it needs a high involvement. However your time is precious and you understand the importance of each project on the success of your organization. As you get closer to BAU kind of work, it might be fine to have limited involvement. But in most disruptive programs it might be easy to follow a rule- Your passion and involvement will go viral! Spread it!
Flawed Comparisons are easy. Shun it!
I don’t think I have walked into a client’s organization where I have not met someone who would have said “Well, blueprinting and waterfall approach has worked well in most complex industry and it’s sad to see how these new IT vendors come up with this new ‘Agile’ concept which hardly can promise what will I get at the end of 2 years”. Well, I might have penned it down a way too brutally but these slight comparisons to ‘old times’ to ‘new times’ are very common. Most of the times it’s about how we have distanced away from more organized and well-defined waterfall approach to new failing approaches.
Construction industry is often quoted and is one of the best example where waterfall approach works well. It’s industry where division of labour works. The industry has matured over centuries. There are tons of other reasons why waterfall has worked well for construction industry.
Software is ever evolving based on your needs, your client’s need, your competitors. If we suspect scope to change as we discover more, it’s best to work in a fail fast approach of software development where we are building pieces which can receive feedback faster so that we can improvise and groom our backlog to reflect new thinking, new discoveries and disruptive industry out.
Agile is not a methodology, it’s a way a thinking. If your tech partner has the real agility, they would adopt to new challenges you pose to them, there would always be new door that opens up with new challenge. If you hear term ‘agile’, you should be able to see how your software is shaping up from perhaps 15 days from the start of the project. However, you should be actively involved in the project; look at the product every two week, provide feedback on product, actively participating in grooming the backlog and even look for opportunities to gather feedback from your end users. One major change that you might have to adopt is that you have to start with the premise — “perhaps what I know today is not sufficient and is bound to change” which means you will always look for more ways to validate your product at regular interval. These validations are magical because your skepticism will help you be more open to feedbacks and help course correct.
Most of the time, division of labour pulls you down in software, if you have a front end team, Java team, Python team, infrastructure team…you probably are dealing with too many dependencies to take your product out to the market, or you would have spent 50% more time in defining the handovers and consumption patterns and by the time your development team is able to consume them, the technology landscape would have changed/ upgraded and there would be a better/ leaner/ easier way of doing the same thing.
At this point do you switch to new technology? (and create new set of handovers definition yet again!)
Do you continue with your old way of working?(and probably lose your your tech architect who knows there is better way of doing the same and might get frustrated enough to leave you and join more progressive firm)
Would you rather create smaller vertical pieces which you can put to market faster and increase the chances of your product adoptability.
I have used over simplifications in my examples but I am happy to discuss scenarios if you write down in the comment section below
Biases are all around. Put a check on them!
Have you been part of the huddle where design, product and tech are fighting with each other and you seem to relate and understand the problem of one side more than other sides? It’s quite likely that your own background might have created a bias and you tend to take sides. Also because you relate to one group more than other it’s also likely that you tend to discuss your ideas with this one group more often than with others. As a project sponsor you will have to keep this check where you appreciate pains of all the sides and also impart information to all as a group. You do not want to create a product which has the best User Interface but fail at basic functionality level. You definitely should not work on creating power centers of information!
Good that you are measuring. Better measure it right!
Measuring is a tough game and measuring it right takes a lot of time. It’s really important to know what you are measuring?
Do you want to know when will your product ship out? Do you want to know if you are being charged right? Do you want to know if there are fine prints in your partner’s work which you are unaware of (Are their details hidden from you and will be told to you at nth moment!)?
Most of the times the additional metrics that are added are because of the last reason — You just want to ensure that your vendor can not cheat you or take you for granted. Take your time, understand your Tech Partner’s organization, understand the toughest project they have delivered and judge how they achieved past successes. It’s not always easy to find the tech partner of your choice, if you feel you do not know them enough it might be worthwhile to enter into relationship with new innovative commercial models. There can be risks and rewards attached at the commercial level which can increase accountability at both the sides.
The only good measure of end product is user adoptability. Convert that statement into goals and then to tasks. Ensure that each iteration is bringing the product closer to end user’s goals.
There are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know. — Donald Rumsfeld
A good project management will insure you against most of your known-known (issues reported and addresses) and known-unknown(risks assessed and planning done to mitigate should one risk appear).
If you are measuring the product against a deadline, understand there will be unknowns-unknowns. There might not be much logic why your Technology partner will not face these unknowns. You have to add unknowns-unknowns before you communicate launch date to your end users.
Only a great cohesive team can help you pass through unknown-unknown. This is the team who is confident of their technology, product management, user experience and project management skills. It would be a constant struggle that you would have to face when you choose your technology partner— What is most important thing I should seek when choosing my Tech partner— Domain experience? Confidence of solving any unknown problems? Technical capability? Culture?
Getting a product out in-front of end users at stipulated time, with reasonable scope and agreeable budget is a moment of all smiles! It might be worthwhile to do a slight introspection so that you can change (if needed) and bring out the best out of your technology partners while ensuring that your ambitious mission is achieved.