Two weeks ago, I wrote about ways in which I have worked with sales to build stronger relationships and effectively protect my business, team, and clients. In so doing, we had fewer projects that we couldn't support and a stronger ability to plan resource needs. It wasn't perfect, but it was better than the Wild West scenario that I described toward the end of the post.
As promised (although a week late), I want to share 10 things I have done in the past to ensure I had or was able to get the resources I needed when I needed them. With that said, there is no silver bullet. Your ability to get what you needs is dependent on a lot of outside factors. Things like:
As promised (although a week late), I want to share 10 things I have done in the past to ensure I had or was able to get the resources I needed when I needed them. With that said, there is no silver bullet. Your ability to get what you needs is dependent on a lot of outside factors. Things like:
- Economic Environment: The Services business may be killing it, but sales overall may be down; Management may impose a hiring freeze across the board, and you have to get it done with less.
- Product Development Cycles: You may have a need for a member of the Engineering team, but they have a critical release and can't step away. You have to figure it out on your own or delay your client.
- Corporate Philosophy: Let's face it, not all departments are created equal, and if you work in an organization that pays lip service to the value Services provides, you will have a difficult time getting what you need, no matter what you do. (I've been there!)
- Perceived Role of Services: If Services is perceived first and foremost as a profit center, almost every decision will be made based on the impact it has on margin, regardless of the impact elsewhere. That is not to say you can't get what you need, but you need to understand this fact and position your business case in this context.
So, here are 10 things I have done in the past to get the resources I need when I need then.
- Working with Sales to Manage What Is Sold and Understand Your Pipeline: I discussed this first action in depth in my last post. In the end, you need to be perceived as part of the sales team, helping to close deals, but you also need to clearly articulate your constraints and the impact of bad projects on the clients and the business. Its a relationship play - start now.
- Effective Project Estimation to Understand Your Pipeline and Backlog Better: How many of us really feel confident in the estimates we put forth? Do we really have the information we need from the client? Do we understand all the risks, and have we mitigated them effectively through contingency? Have we taken the time to assess past projects "like this one" to ensure that we have historical information that supports this estimate? If you miss the estimate by any significant margin, your capacity planning will be wrong and you may not have the resources you need when you need them. In one role, my team and I developed a five-day "jumpstart" engagement. We sold it for $12,500 as a standard offering. We assumed five days of effort for pre-engagement planning, execution, and post-engagement wrap up. We sold more than I can ever guess in this model. We eventually went back and evaluated the time sheets of these engagements and found that no engagement was actually completed in five days. For every day of client-facing work, there was at least 1/2 day of non-client-facing work we needed to do. Our five-day engagement was really eight days. We adjusted our time estimate and our pricing. In so doing, we increased revenue, improved our margin, and had more effective capacity planning. We had the resources we needed when we needed them.
- Using Earned Value Analysis (EVA) to Assess Project Trajectory: I feel like I am aging myself with the EVA reference...does anyone use EVA any more? Well even it if it is not used formally in this agile development world, I think the concept still holds true. At the most basic level, EVA is an assessment of the likelihood a project will complete on time on budget based on what has been completed to date. Are you 50% complete with the work but have consumed 60% of the budget? If yes, your EVA would indicate a cost/time over run. Likewise, if you are 50% complete with the work but have consumed 40% of the budget, the EVA would indicate on-time, on-budget (or ahead of schedule) delivery. Now, we all know that past performance is not a promise of future performance, but it is an indicator you can use to determine if resources are likely rolling off projects when initially planned. You can then start to think about whether you have a scheduling conflict with another project for which you need the same resources or if you will be able to start a future project sooner or crash a schedule by adding additional resources since they may be available.
- Setting Project Managers' Expectations on the Importance of Project Plan Updates for Effective Backlog Burn Rates: I have seen too many times a PM running to a resource manager in a panic because he didn't communicate that he needed "this" resources for two more weeks, and the resource just casually mentioned that she will be in Tuscan next week starting her next gig. Like it or not, the PMs hold the keys to ensure that the right information is communicated early and often so that adjustments can be made earlier to avoid strain in the system. As project managers (PM) are assessing a project's status, using EVA and other tools, they should be expected to make updates to project and resource plans in what every system you use (PSA, Spreadsheets, Staff Meetings, etc.) to effectively communicate to management capacity needs on a project. Without the input from the PMs, resource managers will be in the dark about what resources are needed when. Setting PMs expectations on what happens when they do or don't communicate schedule changes is key to making it happen.
- Use Monthly Capacity Planning Reports and Meetings with Finance: Similarly to the post on working with Sales, Finance holds a big key as to whether you get what you need or not. The more they understand your business and trust your models, the more confidence they will have in the business cases you put forth and, barring any external factors, the more likely they will be to go to bat for you if you need something out of plan. I have found that providing regular reports to finance on revenue, margin, and capacity (existing vs. planned) ensures that the right level of regular communication is happening and provides a forum when you need it to ask for more. Again, there is no silver bullet, but if you have a regular mode of communication and a relationship with Finance, they are more willing to listen when you need their help.
- Managing "Product Quality Issues" Internally: Embedded Services Organizations often find themselves doing work to overcome a bug in the product they support rather than doing the consulting work they were hired to do. In some cases, the level of product quality issues (PQI) is fairly benign. In other cases, services is working with a difficult product with a lot of bugs and issues. In one organization that I managed, the amount of time we were spending addressing product issues in our projects was having a dramatic impact on our ability to complete work on time, which affected customer satisfaction, practice revenues and margins, and our ability to manage our resources and project schedules. The solution? We added a "PQI" task to all projects, set some ground rules for how/when to use it (including some governance to avoid abuse), and reported this time regularly to our Product Management and Engineering partners, as well as to Finance. This allowed us to 1) more easily get the engineering resources we needed on projects where PQI was an issue, 2) include enough contingency on projects where we expected to have significant PQI time based on historical projects - allowing better resource planning, and 3) improve employee satisfaction since we gave utilization credit to the consultants for this time. Product management also had more visibility into the issues that were causing the most pain for Services, our partners, and our customers and could prioritize their sustaining efforts accordingly.
- Measuring and Managing Goodwill Work: Similar to PQI, Services is often called upon by Sales or Executive Leadership to deliver what I call Goodwill Work (free consulting or significantly discounted consulting) to make up for a misstep by sales, support, marketing, or a product issue or to ensure we get that "big deal we really need to make our number this quarter." These requests are often unplanned and urgent, which is a huge problem when we are fully utilized with a 6-8 backlog of work to get done. It is important to track the amount of Goodwill Work you and your team are delivering and reporting that back to management. I have even gone so far as to use historical numbers to budget a certain percent of my teams billable time to Goodwill Work and to develop a model with Sales and Executive Leadership on how it can/should be used, what approvals are needed, and what happens where the budget is fully consumed. Reporting on Goodwill Work gives you a leg to stand on when you need more resources to support a project. Planning and budgeting for it makes the issue transparent and forces the organization to make difficult decisions about when to use it and when not.
- Mantra: Services Can't Outpace Product: In some cases, I believe that custom services can be used as "paid R&D" where a customer wants a new product feature, it is not on the roadmap, and services has the capability to build it for a fee for the customer. The conversation can go like this, "That feature is scheduled for Q2 next year. You can either wait until then, or we can develop a custom SOW and have our Services organization build it for you now. It will cost you $500,000 (or what ever), and will be made available to all customers as soon as it is fully tested." Some customers will feel it is worth the money to get the feature now. Others will simply decide to wait. In some organizations, the Services team does not have the skills to take on such an effort, and the mantra must be "Services cannot outpace product." In other words, sales cannot sell custom development of any kind without knowing that Product Management and Engineering, not Services, is prepared to support the effort - for a fee or not. (Please see last week's post on working with Sales to get what you need.) Assuming this mantra is communicated and well understood, and the right Services Engagement processes have been defined and are followed, surprise custom engagements should be few and far between.
- Marketing and Sales Can Influence But Cannot Define What Services Will Deliver: Years ago, I worked for a small, but fast growing product company. We came out with a new product and Marketing, in a vacuum, developed a "packaged offering" that includes five days of Professional Services. Every time a sales rep sold this new product, Services was attached. Awesome...? On one hand, I was very pleased that Marketing and Sales understood the need and value of Services and included us in the package. On the other hand, I was scared to death when the Sales team was educated on this new package and I had never been brought into the discussion - what exactly are we expected to do in five days? As I dug in, my biggest fear was confirmed. Marketing designed a five-day engagement that could never, ever be delivered in five days. Their number one concern was developing a packaged offering that met a price point that Sales could sell, but they built something that could not be delivered in the time they committed. My margin would be impacted, I'd need to adjust my pipeline/backlog model to include a multiplier to ensure we captured the right resource needs for scheduling and capacity planning, and customers would be very disappointed when the work took 10-15 days and their deadlines were missed. A few failed projects and unhappy customers later, and Marketing learned why they needed to engage with Services when defining new offerings. From then on out, no Services offerings were defined without input and approval from Services.
- The Role of Services Must Be Understood Across the Organization: Are we a profit center? If yes, no PQI, no Goodwill, no discounts...period. Every decision is made based on our ability to drive revenue and margin. Alternatively, Are we an engine to drive product adoption and satisfaction? If yes, we need ground rules for all the items listed above, but we focus less on driving margin and more on the overall contribution Services makes to the corporation. The challenge comes in when Finance sees Services as margin business first, and Sales/Marketing wants and needs us to drive adoption and growth within our customer base. My philosophy is that Services Organizations in product companies have to understand that we are a product company and everything we do should be to drive adoption of the product. I believe that Services should be profitable, don't get me wrong, but you won't get 40-60% profit margins AND address PQI and Goodwill on a regular basis. 15-25% is much more likely.
At the end of the day, and as I mentioned above, there is no silver bullet, you can do all this and more and still not get what you need if the value of Services is not understood or appreciated or if the overall health of the business is failing. Regular communication on items such as those above put you in a better position, for sure. You will often need to create strong business cases based on actual data to ultimately get what you need, but if you find that getting what you need is not typical, you should strive to understand if there is a disconnect between what you think the team's role is and what others think it is.
You should also find allies across the company to help you make your case. Will Sales, Marketing, Product Management, and/or Engineering go to bat for you? If you strive to build the right relationships across the organization, I believe, you will find allies. Sales will want you to be able to deliver what they sell. Product Management and Engineering will want you to be able to take care of issues without the use of their team members. If you don't have strong relationships with the leaders of those groups, you will have a harder time getting what you need.
Its not going to be easy...good luck!
No comments:
Post a Comment