Explore: Waverley Software Outsourcing Blog

Every new outsourcing contract discussion must cover pricing. It’s always the subject that people dance around and are often reluctant to talk about.

There are so many ways to price services. Most high end professionals work hourly. Some work on a retainer or monthly for a guaranteed number of hours. Some work on a fixed-bid project basis. And a few will even work for equity. Regardless of the billing agreements, charging for services can test the trust in any buyer-provider relationship.

But shouldn’t pricing be as easy and transparent as every other part of the relationship? Don’t you want to feel confident that you’re not only getting a good deal, but that you can trust your software service provider to bring their best people and practices to the table?

You’re running a complex business and don’t want surprises. You may be pleased if your provider worked extra to meet that important deadline, but not so pleased when you receive a bill that is 40% more than what you expected.

What most customers look for in pricing is this:
• a predictable burn rate
• a simple pricing structure
• open communication and transparency when changes to a project (e.g. requirements) affect pricing

There is more than one way to meet these criteria. The approach Waverley uses (after a lot of experimenting) is to use time-and-materials pricing and a simple, inclusive hourly-rate pricing structure.

On Waverley projects we provide a team of full-time people and charge for those people on a flat-rate basis. This means that all costs are included except for obvious exclusions such travel, shipping, and special hardware or software that only you may have. Regular client management and onshore and offshore engineering management is always included. The billing rate includes insurance, computers, and a good place for our engineers to work. We can even keep the lights on through an emergency (some locations have large scale power generation facilities). Waverley continually invests to improve our service and tools. We travel to our offices to make sure all is working properly.

As I said, this isn’t the only way for you to feel that you are getting a fair deal from your outsourcer. The main thing with pricing is to be confident that your outsourcer is meeting your need for predictability, simplicity, and transparency.

Effective software development teams have defined communication paths that help guide how projects are run. One important path governs what to do when a customer finds a defect in the software. The bug gets reported, logged, prioritized. The priority of the bug determines when it will be evaluated and fixed.

But what if the rules don’t work? What if a low-priority bug is happening to a high priority person - for example, an executive under pressure to deliver who may unreasonably question the project design and has the political means to damage the overall project? Suddenly it’s time to escalate and go outside the normal rules.

This is exactly the situation that arose this week. I’ll tell you how we handled it, but first some background.

A pilot program under threat

One of our development teams is piloting a recently completed large application. The pilot is going well, at least it was until I got a call from the Program Manager for the client. This Program Manager is as steady as a rock, so if he calls and says he’s concerned, I sit up and pay attention. On this call he’s concerned, and I’m paying attention.

The issue was that two of the pilot users were having a problem with the application and were making their frustration known to a lot of people, including the CIO. Although the problem had been logged with the development team, it did not get a high priority based on its description. The development team was focused on completing an iteration and so this problem was on the list of bugs and would be considered when prioritizing the backlog for a future iteration. Standard development methodology here.

The symptom that the two users were experiencing was this: a request to the application that should normally take less than two seconds was taking 45 seconds. As you can imagine, they found this troublesome.

Redirecting the team

After I got off the phone with the Program Manager, I immediately contacted the manager of the development team in Romania and explained the situation. We agreed that we needed to immediately focus the development team and the QA team on fixing this bug.

Of course, when the developers tried to replicate the problem at their lab, they couldn’t. The application performed perfectly.

It wasn’t until they could actually gain remote access to the user’s computer that they could see the problem. What did it turn out to be? The local database for the application wasn’t indexing properly and so some queries to the database were taking much longer than they should. The developers were able to quickly fix the problem by running a simple script once they identified its source. The script was included in a future patch to be sure this problem would not resurface and we reviewed our release procedures and patch creation process to look for anything we could improve in a future release. Finally, we checked back with the two pilot users to make sure they were satisfied with the software.

What’s the takeaway?

Once the developers fixed the problem and restored the user’s application to its normal state, their job was done. As for me, I still had plenty of work to do to reassure the Program Manager, our Sponsor, and the CIO that the problem was an isolated one, that it was a simple problem and that it did not reflect any fundamental underlying issues with the application.

What does this experience tell me? I don’t think it’s that we should change our procedure for fixing bugs. My takeaway is that even if a development team has a good set of procedures and communication policy in place, some situations will arise that require escalation. In these cases, the Client Manager has to change the team’s priorities and put all its energy into fixing the immediate problem. It also points out the importance of an effective escalation path so that the client always has someone to go to when the conditions are extraordinary.

In the scheme of the whole project, this kind of escalation is unproductive. The problem the two pilot users were experiencing would have been resolved in due course. Escalating an entire QA team for 36 hours prevented other issues from being worked on, so there was likely a small schedule hit as a result of the team being quickly redirected, then redirected again when the bug is resolved. But sometimes, despite the productivity hit, it’s necessary to parachute in the swat team so that the client can manage internal expectations and politics. We understand this is the reality for our client, and we work to support them as best we can. But for everyone’s sanity and for the continuity of the project, we try to keep these fire drills to a minimum.

Picture these situations:

Three engineers from different groups talking at lunch about a difficult bug that one of them had spend most of the night fixing. Nothing wrong with that, right? Just some colleagues talking informally about their work.

The Product Manager meets with the User Interface Design Group to decide about priorities for the next release. Once again, perfectly appropriate. Part of the job of the Product Manager is to establish release priorities. Meeting with each engineering group is one of the ways this gets done.

A Sales Account Manager asks an Engineer to make a change in the next release that a customer has asked for. Oops. We just crossed a line here. We would expect the Account Manager to advocate on behalf of a customer, but going straight to the Engineer is the wrong way to do it.

The Client Project Manager calls an Engineer at a vendor firm to ask how a particular feature in the application works. The line just got crossed again. The Project Manager for the client should have a primary person, probably a Client Manager, who can field these calls for the client. It’s not that the client can’t get these questions answered, it’s just that they should be answered in the most productive way possible.

These examples point clearly to the need for defining communication paths for project teams. But how can you define them in a way that encourages helpful informal communication and that also ensures necessary formal communication?

At one extreme you could view a project team as a network with potential connections from each member of the team to every other member of the team. But if everyone talked to everyone else, life would be chaotic and the team would never reach its goals.

At the other end of the spectrum you could have tightly controlled communication that defines exactly who can speak to whom. This approach allows for no flexibility in the system and is overly restrictive.

Finding the middle

The answer of course lies somewhere in the middle. What is that middle?

Before I answer the question, let’s look at the difference between formal and informal communication. At Waverley we think of formal communication as any communication that causes a person to change work priorities, goals, or that affects productivity. Everything else is informal.

So according to this definition, formal communication includes obvious events like team meetings, client email, design reviews. It also includes any nonessential and lengthy calls to engineers by the client.

The way to find the middle is to define communication paths – not to the degree that they limit informal communication – but so that formal communication can proceed in a predictable and productive way.

The communication paths in distributed teams are controllable, even across remote locations, if everyone on the team understands and plays by the basic rules.

Early definition of communication paths will help avoid problems. As the project evolves, communication paths can evolve with them.

So how does a team go about defining communication paths? It starts by defining roles, then by looking at groups of roles, and finally at paths between groups.

That’s what I’ll be examining in my next two posts.

Recently Waverley was invited to become a Microsoft Preferred Vendor (MSVP). This is a big deal for a company our size, especially since our work at Microsoft contributes directly to their software products. Microsoft has about 60,000 vendors, but only 1,000 of them have the Preferred Vendor status.

The list of Preferred Vendors includes software developers like Waverley that are hired to support Microsoft’s supply chain. It also includes all the other ancillary services that a big company purchases, for example security and food concessions.

Like all large companies, Microsoft is always looking to become more efficient in its purchasing. Each year Microsoft purchases about $12 billion of goods and services. Currently 75% of those purchases are funneled through Preferred Vendors. Microsoft is trying to increase that percentage.

Microsoft’s annual vendor summit

Microsoft hosts an annual MSVP summit in Redmond at its impressive corporate campus. I went up to Redmond last week to attend. I was expecting a day of dry presentations, but was pleasantly surprised.

Why? The first surprise was to see the level of effort that Microsoft puts into making vendor relations work. Most of the topics were predictable: what Microsoft expects from vendors, quality initiatives, payment logistics, and training. But I was impressed with the quality of the programs and the obvious desire to make them work for both Microsoft and the vendors.

Bill Gates and creative capitalism

My biggest surprise was to see how Bill Gate’s ideas about philanthropy and sustainability are finding their way into Microsoft’s vendor programs. As a full-time philanthropist Gates has spoken about the need for more integration between philanthropy and business, something he calls “creative capitalism.”

At the summit Microsoft encouraged its vendors to also start thinking about creative capitalism and the responsibility of all companies to think about their obligations to customers, employees, shareholders and the broader community.

The idea of responsibility not just to profitability, but also to customers and employees is not a new one for me. It’s a big part of why we founded Waverley.

But Microsoft’s encouragement to also consider responsibility to the broader community is a compelling idea. As a young and growing company it’s not something we felt we had the resources for. But my day in Redmond made us reconsider. It certainly gave me something to think about on the way home.

Overall, a useful trip.

We’ve written  about the disadvantage of fixed-price contracts for agile programming projects before - why fixed-price makes sense for business process outsourcing with its predictable outcomes, but not so much for agile development.

Our main argument was that avoiding fixed-price gives you more flexibility to define your business requirements. You don’t have to know all your requirements at the beginning of an agile project.

Artem Marchenko recently expanded on this argument with two additional sources of flexibility. One is technical obstacles that may be impossible to predict at the outset of the project.

And the second is changing market conditions. The source of this change could be at the micro level (e.g. a competitor enters the market) or a changing macro-economy.

As Artem puts it, “Agile methods acknowledge the market and project uncertainties and try to adapt by building software in small and completely done increments.”

He also points to some additional articles on the subject of agile development and fixed-bid contracts, both pro and con.

How does a company manage financial risk if the project cost isn’t fixed? A company can always set an internal cost goal and end iterations when it’s reached - that would help them manage their content iteration by iteration. The beauty of agile is that there’s something ready to go out after every iteration.

I’m seeing lots of articles in the trade press on reductions in IT spending as growth in the overall economy slows. You’ve probably seen them too.

CIO magazine says IT Leaders Can Slash Nearly 40 Percent of their Spending while ComputerWorld gravely announces 2008 IT spending forecast again cut by Forrester.

Many of the measures that CIO Magazine recommends are focused on operations - reducing telecom spending, renegotiating IT operations outsourcing contracts, and data center consolidation. But they also recommend improving the “efficiency of application development and implementation processes.”

In our work with clients, we’ve found many ways to improve the efficiency of application development, regardless of how the economy is doing. That’s the big advantage of iterative and rapid methods like agile development.

If priorities change in the middle of a project (like when the economy turns South and budgets get cut), you can go back to the Four Dials Exercise and change your priorities. And if that means modifying the project deliverables and schedule, here are some ways that agile methods make it less painful:

• Focus on strategic elements. Essentially, this means you’ll have to generate a list of requirements and then carefully prioritize them. Work on your highest priority items first. It will limit distractions. Resist the temptation to make everything a number one priority. By definition, only one priority can really be number one. Figure out what it is and then stay focused on getting it done.
• Adjust priorities. Periodically look at your priority list and make adjustments. Some things may become more important to do, others less so depending on business needs and what drives your organization. Elapsed time can also factor into your prioritization. Keep focusing on the top priority items and make sure they are done before you move on and look at the list again.
• Remove waste from the process. For each task at hand, focus on what needs to be done to make that task successful. Make sure the requirements are defined and all the inputs needed for success are satisfied. If you don’t know exactly why the team is doing something or don’t have the inputs needed to make it successful, then stop that task and do something else. Ask if the task is still needed and what needs to be done on the input side to complete the task on the second try. Make sure your team and outsourcing partners have clear direction and know what they need to do. Spend the time to make sure questions are answered promptly so that efficiency is kept to a maximum. Driving efficiency and productivity through good management are key to removing waste and squeezing the most out of your resources and time.

Eventually the economy (and your budget) will pick up again. When it does, you can re-examine the items that were postponed and evaluate whether it makes sense to bring them back into the project.

The four constraints of project management

Every project has four dimensions to manage: scope, cost, schedule and quality.

• Scope: For software projects, scope is the project requirements list. Typically, this includes performance requirements and a set of features. To increase the scope, add features or make existing features on the list; to decrease the scope, remove or simplify features or reduce performance requirements.
• Cost: For software projects, cost is primarily contained in resources needed for the project.
• Schedule: The schedule for software projects is typically prioritized using the desired release date. If interim dates (alpha, beta, feature freeze, code freeze, etc.) are determining factors, these dates may be prioritized separately.
• Quality: Many models prioritize based on the previous three dimensions only. Unfortunately, what usually drops is the quality of the product or at least the testing time. It is important to realize that the quality of a software product is directly influenced by the other project dimensions. Occasionally the product quality is of lesser importance than other dimensions – for example to meet the deadline for a demonstration or marketing event.

Not only do you have to establish the goals within each of these categories, you have to prioritize the four dimensions. These priorities establish the constraints on the project.

Setting priorities

Working on a big software project involves managing risk, handling unexpected tasks and absorbing competing priorities from external influences. These influences include investors, management, and customers.

Successfully navigating such a complex task requires that you understand and steadfastly follow your most important priorities. Even more important, your team needs to be as resolute about these priorities as you are.

Here’s what often happens. The project sponsor makes the priorities clear at the onset of the project. It might be schedule and cost, or quality and scope, or some other pair of project dimensions.

The members of the team nod in agreement about these priorities and the project begins. Then, at some point, it becomes clear that different members of the team have a different understanding of the priorities. Although there was a lot of head-nodding at the beginning, the team hadn’t fully internalized the constraints on the project.

How can the project sponsor and project manager help the team to follow critical project priorities?

The Four Dials Exercise

Here’s an exercise that we use at Waverley to make sure the entire team understands and stays focused on the top priorities that will determine the project’s success.

In a team meeting, explain the four project dimensions to participants and discuss the purpose of setting the guiding criteria for the project. Then ask each team member to vote on the two dimensions that he or she believes are most important.

Record the votes for each person’s top two dimensions and tally the votes. For the exercise, treat every vote equally.

As a sponsor or program manager, you probably have already decided the outcome you or your management feel is necessary to guide the project. If your expectations disagree with the voting results, discuss these differences. This discussion provides an opportunity for the project sponsor or the project manager to walk through the reasoning that was used to set the priorities. It also is an opportunity for team members who understood the priorities differently to voice their views and for the group to reconcile these views.

Because the project hasn’t started yet, it’s safe for people to have different views and for these views to be discussed. The goal is to make clear to everyone what dimensions are most important to the project sponsor, for alternative views to get an airing, and to reconcile differences.

All other decisions made during the course of the project relate back to the constraints that are established at the beginning of the project. The Four Dials Exercise increases the probability that the entire team will internalize the priorities and make decisions that support them.

Fighting overconfidence

Why does this exercise work? Chip and Dan Heath, in their book  Made To Stick, explain that one of the ways to make an idea stick in a person’s mind is to introduce an idea that is unexpected, if the answer surprises us. One of the best ways to create surprise is with a mystery, a gap between what we know and what we don’t know. People generally want to solve a mystery and so it’s easier to keep their attention.

But often people are overconfident about how much they know. If, at the beginning of the project we told the team to remember the top priorities of the project and then reminded them of the priorities, the tendency would be for team members to be overconfident, to say to themselves “I already know this”, and to tune out.

By taking a vote at the beginning of the meeting, we are asking everyone to commit to their answer. The Heaths explain that this simple act of committing causes everyone to be “more engaged and more curious about the outcome.”

Fern Mandelbaum is a partner at Monitor Ventures where she specializes in venture funding for technology-focused businesses.

In addition to investing, she works closely with companies in her portfolio to refine their business concepts and to recruit management teams, key advisors and board members.

Her portfolio includes: Limelife, Greystripe, Buzzd, and the Experience Project.

Fern was co-founder and CEO of Skyline Products, which she grew and then sold to IDEO Product Development. Prior to co-founding Skyline, Fern worked at SRI International, HP, the Kyoto Bank and Bain and Company.

Fern received her MBA from Stanford Graduate School of Business and her BA in Economics from Brown University.

I met Fern recently at a fundraising event and we found that we had a similar outlook on collaboration and building teams. She graciously agreed to let me interview her on these topics.

Matt: What’s the most critical factor for the success of a startup?

Fern: It’s all about the team, how well the team executes and works together. Good ideas are of course a given requirement, but the team is what makes or breaks the business.

Matt: When looking at a new team, what are you looking for in a CEO?

Fern: Generally, the CEO and her team need the perseverance and commitment to see it through and attract great team members. Specifically, the CEO needs to have these characteristics:

• Great listener. This is critically important. None of us know everything, so a CEO needs to listen well to make good decisions.
• Coachable.
• Drive.
• Motivation. Making money is not the only factor.
• Passion. A love and sense of excitement for what he works on every day.

Matt: Is there a formula for finding the right people?

Fern: No. Intuition about people is important.

Matt: How do you find the rest of the team?

Fern: It’s important not to rush. Remember, it’s easy to hire people, but much harder and more damaging to the business to fire them. Working with the right team members is a lot like a marriage. You don’t rush into a marriage and setting up the management team is the same. Let it take it’s time. Spend lots of time getting to know them. Work your network looking for the right people. Get recommendations, do lots of talking and listening to the people you think you’d like to work with.

Matt: What about working with people on the outside of the company?

Fern: It’s important to use the best talent available. Sometimes they are contractors, or outsourced. It’s important to be flexible and nimble.

Have you ever worked with a software project team that treated the project as a black box, providing regular updates but little insight into their daily workings? Whether the team is internal or external to the company, this is a frustrating experience. It does little to create trust in the schedule or confidence in the outcome.

More transparency is better when it comes to software projects. It means that both team members and senior managers know WHEN the project will achieve goals and milestones. But, more importantly, they know HOW the team will get there.

In Applied Software Management, Andrew Stellman and Jennifer Greene recommend that project managers do everything out in the open, first by publishing the work products and second by making decisions based on known guidelines.

Publishing your work in a public repository gives everyone access to the project information at all times. No one has to be concerned that they don’t have the full picture or that someone is hiding something. It also improves the quality of everyone’s work. If a person knows that their work is visible to everyone, it provides a big incentive to produce quality work.

Making decisions based on known guidelines also reduces concerns. Team members and managers learn that the project manager makes decisions in a predictable manner.

Transparency is about letting the entire team see who does the work, how the work is done, and what results it produces. It enables managers and other team members to speak with each other as needed and reduces the risk of individuals feeling left out of the decision making process.

Can transparency go too far? Yes, when transparency is abused and pushed beyond what it is intended for, a software project can suffer from inefficiency, delays and eventually a complete breakdown. Team members need to get work done, and can’t constantly respond to unnecessary inquiries.

The solution to this communication issue lies with clear roles and effective project management, not with information transparency. We’ve found that transparency has to be coupled with good communication between the lead members of the project team and the senior managers. These leads can include the project manager, technical and QA leads, and relationship managers and others.

Once you set up the responsibilities of these key people and how they communicate, your internal customers will become comfortable with their ability to manage their risks. They’ll know how and where to the get the information they need. And they’ll know who to talk to when they have questions or issues to resolve.

Finding great programmers is almost an art form. It takes years of experience in the software business to really know what to look for. It also takes a team of great programmers to recognize and attract more great programmers. This article does a very nice job covering the kinds of things you should be looking for. These are also the same traits you should be looking for in a potential outsourcing partner.