Most successful software development companies sooner or later come to a challenging moment in their journey – the start of providing services for enterprise type of customers. In this brief, I’ll shed some light on why it’s challenging and what to pay attention to, to smoothen things up and increase chances for delivering expected outcomes.
Artykuł sponsorowanyThere’s already plenty of material covering this topic and below is just my subjective, personal view, not a complimentary analysis.
A few chosen characteristics of non-IT mature enterprise customers
To say that there’s plenty of stakeholders in the enterprise world, often having conflicting needs and priorities, seems very obvious. But what’s worth mentioning is that these stakeholders are usually not dedicated project resources. They are typically assigned to support the project while performing their daily work or working on other “more important” tasks. Their time is usually very much limited and has to be respected and consumed wisely. Another important factor to note is that their decision-making process is slow and dispersed and may take more time than ever planned for. Awaiting approvals, inputs, decisions, which are being deferred to others can quickly grow the famous parking lot to become one big blocker. There are also hidden agendas, politics, and often internal opposition at the customer end, which may double the trouble. While the project you’re working on may be sponsored by unit X, unit Y is looking to immediately consume some of it and is putting more pressure, unit Z doesn’t like it at all, and VP of technology does see it all differently. And yes… it will all surely turn things upside down in your project plan. Your mastery in dancing the salmon dance to handle it all is indeed helpful here, but only as long as there’s someone at the customer end who can review and decide. In reality, you may face the situation where there’s no single decision maker in the project and responsibility is shared.
Going to work with an enterprise you could assume it’s all so perfectly advanced, all documentation on systems is available, all processes set in stone, all data easily accessible, plenty of knowledgeable SMEs around… While in some cases it may be true, I’ve observed it many times that the governance can be so poor that you’re the one who eventually sorts it all out. Also, their organically grown enterprise architecture may be obsolete, not secure, compliant, or working, and you somehow must make good use of it. In addition, the “SMEs” often turn to be quite uneducated and disconnected guys, who have never worked on a complex project and have a very foggy idea on the solution you’re going to build. Regardless of all the circumstances, the customer still expects you to build a top-class solution, plan it all end to end, commit to deadlines, and stick to it like glue. From my experience, scope and quality could be negotiable, but when it comes to time and money, these are constraints you don’t want to touch. So, if you need to cut on something, remember the focus is on outcomes, rather than detailed processes and governance perfection.
All in all, despite all the challenges, the enterprise adventure is definitely worth going for. It can be super rewarding as these customers usually prefer long-term cooperation with one vendor covering all areas, than with a few, separate and competing ones. All you need to do is build trust and prove you can deliver on promises…
A few things to keep in mind to increase your chances of successful delivery
First of all, although it should have been already done at the presales stage, you still need to do your customer environment analysis. Look at business seasonality, trends, financials, competitors, markets to understand motivators, risks, and threats. Explore customer business organization, structures, key stakeholders, marketing, and investment data as it may help you understanding dependencies on portfolio level and to answer a question: how do we fit into the overall transformation strategy? It will help identify detractors and hidden agendas and should allow you to balance and avoid a situation when a trivial issue becomes a huge escalation.
When you learn more about your customer, you may realize that sometimes a little mindset transformation is a must. While most of the IT world is already more than familiar with Scrum or any other Agile delivery framework, some large enterprises are still testing the agile waters and are still underestimating the value it brings. There are many reasons behind this, but the biggest fear seems to be expected lack of predictability, which these companies got used to. Due to hierarchical structures and reporting, plenty of internal and external dependencies and commitments, these customers tend to look for waterfall style end-to-end project plans. Therefore, there’s usually a need to align on project delivery framework, to combine goals of fairly efficient development with structured, time-boxed and waterfall style delivery. Internally, for the project team, it may mean (depending on the experience of team members), a slight need to re-shape their approach and the PM role here is crucial. PM should provide customer perspective, explain all the circumstances and limitations to the team members, brainstorm on everyone’s “universal” best practices, and once all internal storming is done, align with the customer. The team must understand that Scrum is good as long as it brings expected outcomes and sometimes we need to get more agile and agree on a fit-for-purpose delivery model. The other part of this approach transformation is to reshape yourself and your whole project team from doers to advisors/consultants. These days the enterprise customers are looking more and more for in-depth advisory and guidance. A vendor must show confidence in everything they do and everyone in the project team must be proactive and act as a strong SME, with no doubts or hesitations. If you achieve all that, you’re on the right path to building trust, which is the key factor for efficient collaboration. You should also consider enabling direct collaboration of your project leads with their counterparts to make them your allies. And of course, by all means, try to make customer PM your ally. There’s been so much said about how to do this, so I will only mention that you should always show that you care and are ready to go above and beyond to address all the needs (stay realistic though – overcommitment is worse than keeping it real). Once the trust is built, you can start to be politely demanding – set boundaries for responsibilities, chase for outstanding actions and blockers on a regular basis, be sure to remind about related risks.
The environment complexity mentioned before will also affect project communication and regardless of the effort you put into this, there will be communication gaps. Ask yourself if customer PM is communicating all at her/his end that you assume is being communicated? Or maybe some not that easily digestible messages are getting lost? Why is someone surprised? Dedicate all the time and effort you can to minimize the probability and impact of such closed loops and dead ends. Tailor and scale your communication to what seems to work, use multi-channel communication, be a broken record when needed and most importantly: make sure to involve customer PM in creating the comms plan. And once it’s rolled out, ask for feedback regularly, review the plan just as often and adjust it to the environment dynamics as many times as needed.
Continuing on project governance, many of us are assuming that the more sophisticated documentation is produced the better. Unless the project is being delivered for a heavily regulated industry (i.e. banking), I think that it’s the opposite and all the documentation must be kept as simple as possible. Otherwise, there are slim chances someone will invest enough time into going through it. Similarly, the project plans, roadmaps, reporting, all have to be kept meaningful and simple. Assume that the important people, who may happen to take a look at them, will have limited time and knowledge about the project’s nuances and details. What seems to work best for any enterprise project audience are one-pagers.
While in the project execution phase, keeping in mind that it has to be predictable, apply chosen project forecast vs actuals tracking mechanism, make sure it’s understandable and accessible to key customer stakeholders and report it regularly to keep everyone aware. Ideally, it should also allow you to quickly re-baseline and provide your customer with options and scenarios to choose from in case there are changes or issues. As it is with waterfall planning, there will be variances occurring frequently and flexibility to play with scope or timescales together with your customer can be an eye-opening experience for everyone and can help to prevent some “magical thinking”. Last but not least, the PM must not only keep the project team isolated from external noise as much as possible, but also stay professional and unshaken. And always remember, customer usually doesn’t care about you being successful, unless the success is a common thing.
Senior Project Manager with 10+ years of experience in managing projects, teams, and organizations in both corporate and start-up worlds. He has worked in multiple domains and industries, but his primary focus remains IT. Grzegorz is passionate about building, leading, and retaining multidisciplinary units and teams in a commercial environment. In his spare time, he likes to boost his adrenaline level somewhere on the mountain singletracks.