Monday, June 20, 2011

High Margins in Custom Content Development: An Oxymoron?


If you are in the business of developing custom e-learning content, then you know that high unpredictability and low profit margins are the banes of this business. The reason is simple: design is subjective, and customer expectations are implicit and hard to pin down, resulting in effort overruns and rework. If you serve the Asian market, these problems are further compounded by lower acceptance of e-learning as well as lower training budgets. And if, as a vendor, your business mission is to provide only the highest quality of learning experience to your customers, then you are doomed. Well, not always. 

In one of the companies I worked in, we started measuring project-level profitability only into our 3rd year of operations (c'mon we were a start up) and were shocked to find that our biggest value project was at -80% margin! A year later, we clocked an average of 20% margin. A few years later, the average margin had risen to 60% and very few projects were below the 40% mark. If I use six sigma terminology to describe this change, I would say that we successfully shifted the mean to the level desired and reduced the variation around that mean. No, we didn't achieve this by increasing our rates. In fact, prices dropped by as much as 15% over the last few years because of tough competition and recession-related budget reductions, while expenses all around went up. 

So how did we achieve this? If I were to describe every factor that came into play, I would need to write an entire book. Here I will just share a brief and high-level overview of four top factors that I think were responsible for this change. None of these are new or revolutionary by themselves, but used together in the right balance proved powerful and effective. 

1. Data Capture and the Right Amount of Data Analyses

As in most companies, it was an uphill task bringing about a cultural change towards data capture and data-driven decision making. Fortunately for us, we were a small company and many of us had learned first hand from previous experiences "how not to" do it. The champions of our change process were passionate, training interventions were powerful and the team overall was open minded. 

Knowing that getting to 100% data accuracy would take time and tools, we decided to start analyzing and using data as it was. The journey from individual Excel sheets to an online system with analytics was a long and arduous one, but data analyses began almost from day one. We focused on what was most urgently needed- effort breakdown and profit margins- leaving aside issues like defect and rework for later. 

2. Impeccable Pre-sales Solutioning and Estimation

We took proposals very seriously. Every proposal was developed by one or two senior members of the team, who were experts in designing solutions, extracting customer requirements, and effort estimation. The data we had collected (point 1) formed the basis of effort estimation. In addition to the solution description, each proposal contained a list of all types of assumptions made, and supporting each proposal was an internal document consisting of a bottom-up pricing sheet with detailed effort breakdowns, which would later serve as the project budget sheet.

This upfront clarity and accountability reduced the chances of unexpected requirements coming up later in the development cycle and went a long way in making projects more predictable. Having this clarity also helped in managing the customer later in the project cycle (see point 4). 

3. Reuse at Project Level

How do you reap the benefits of reuse when you are committed to design innovation in every project you handle? How do you train the team for productivity when there are no standards to be followed across projects? After struggling with high production costs for a long time because of what we stood for, we figured out that the solution lay in doing both reuse and standardization cleverly and on smaller scales.

For this to happen, top designers in the team were engaged to build prototypes. They were given freedom and encouraged to come up with different and better designs each time. This served two purposes: it fulfilled the creative urges of the creative team and made the customers very happy. Each prototype contained enough representative screens for the production team to use as a guide. For larger projects, we created visual standards based on the prototype and wrote/marked storyboards accordingly, encouraging both reuse and standardization at project level. This addtional effort made at the start had a great impact on the overall productivity of the project teams.

4. Customer Management 

When I moved from an internal focused role to customer management many years ago, the biggest challenge I faced was in telling customers that they had messed up, while maintaining a positive relationship with them. The solution lay in being transparent and open with customers about effort and budget overruns when they happened (or were about to happen) and not waiting until it was too late to sound alarm bells.

To facilitate this, we started at the very beginning of the cycle with the proposal (point 2) laying out all assumptions in as clear terms as possible. These assumptions were not buried in the proposal only- they would also be highlighted in project kick-off meetings. Once the project was kicked off, bi-weekly health check on projects (point 1) brought possible problems to surface and gave Project Managers tools to deal with the customer. When I say tools, I include the softer aspects of discipline, confidence, vocabulary, tone and urgency. Of course exceptions were made for some customers, but they were few and well thought through. 

In Conclusion

These four factors in no way define a comprehensive list of factors that were responsible for the turnaround in profitability numbers. Many other factors came into play, such as team composition, team skilling, productivity tools etc. A point to note is that all the four factors described above worked towards shifting the onus of project success to earlier parts of the development cycle, namely proposal making and prototyping. I believe that by bringing about this shift, we successfully brought down the variability and uncertainty in the later and more effort intensive parts of the cycle and achieved consistent high margins in all custom engagements. 


  1. Nice One Puja; as always! The subject domain interests me; so a couple of experiences that have also worked..(in addition to all of the above)
    --> Variable resourcing is not a bad thing. It is expensive (by far) but it gives the opportunity to get things done right the first time.

    --> the KISS model--keeping it simply, simple. Project Teams Focus on Customer Sat and Timeline Only. That in itself might be an oxymoron like you say, it lets the project team do, what they do best--simple do projects. Let the bean counters deal with numbers and profitability.

    --> Trust -- It needs to be built. THe Customer is always right, the caveat is --they also need education. A cadillac is not bought for the price of a compact; and more importantly (sorry for the cliche/sexist comment)-- 3 humans cannot produce a baby in 3 months! The PM should be able to deliver the above messaging-- nicely.

  2. Columbus, don't have first hand experience with large scale variable resourcing, but agree with in principle. Project teams not worried about project stats- mixed reaction here. Feel that some form of sensitization and awareness is necessary for everyone in the team. Bean counters can do detailed analyses if that's needed.