In my previous posts on doing better all the time, I talked about getting sales people to sell what management wants them to sell, and about knowing what is profitable before sending sales people in a particular direction. But there is another big roadblock to bringing profitable work on board. It’s the ability to onboard profitably and maintain it once it’s up and running. In short, development services. Even when the actual print production has strong profit on a job or mail piece basis, if it costs hundreds of thousands of dollars to get the business up and running, or you lose the customer before you can get the job up and running, those profits never happen. If the job is cobbled together to meet a date and the code is garbage, maintenance costs (and customer complaints) will eat you alive.

How can this happen?

I have had the opportunity to work with many customers who were transferring business to a new print provider and many print providers who were onboarding new customers. From both sides of the transaction I’ve seen how difficult it can be to get good, or any, development estimates for new jobs. Sometimes the development team is understaffed. In other cases there is a “chicken and egg” process going on where the development team won’t give an estimate without a full business requirements document and the customer isn’t going to go through the process of generating additional documentation until they have decided to change providers. It is particularly amusing to see the dance around this topic for redesign projects where the development team is asking for specs on a redesign that hasn’t happened yet. At many large print organizations there is massive bureaucracy around the creation of estimates and project plans, ironically this is particularly true at so called “agile” companies. At my previous company, I had the operations manager for one of the top transaction printers in the US call me and ask why our development estimates were often less than a third of their internal costs. I said “because my team actually wants the work.”  What is the incentive for an understaffed, overworked development team to stop their current project work to do an estimate on another 3 or 5 new ones? (Answer: Not much unless you create some.)

Then what happens?

Maybe the development team comes up with an estimate with the caveat that “you can’t hold us to that estimate.” Maybe someone else “stubs in” and estimate based on a previous project. Maybe the cost of onboarding is not factored in at all. When the customer is paying for development services, there are potentially ways to manage the process through change requests and clarifying assumptions. If the development costs are being eaten by the printing company, they may end up eating all the profits too. There is more than just development costs at risk. When you don’t know how much effort it will take to onboard a client, you also don’t know how much time it will take. You run the risk of failing your contractual terms to start producing volumes, or placing the customer at risk with their current provider if they have already decided not to renew. Finally, you delay the date on which you can start producing that theoretically profitable print output. Of course, if the development team is constantly in a state of trying to hit deadlines that they did not set, strong, maintainable code is not the result to expect.

Let’s find a better way

There are 4 key factors (not counting the IT platform itself) that go into creating an environment for good estimates and maintainable systems:

• Standards
• Documentation
• Testing
• Development resources

Standards

I mentioned the case of redesign projects where a development estimate is needed for a redesign that hasn’t happened yet. This is one of the places where standards come into play. You need (repeatable) standards for estimating time and costs for programming, or any other service. Standards must detail assumptions (such as number of sections, variables, images, data transformations, and development timeline) and the costs for meeting those assumptions. This is what is referred to as building a box around the assumptions. You define a box, price the box and anything in the customer job that isn’t the same as that box definition requires a change order. Using that approach can take most of the burden off of the development team during the sales process, but ultimately, they must create an accurate estimate once the business is won and customer documentation (or a new design) is provided.

Documentation

The customer should supply documentation of their business requirements and they may also provide a design specification or artwork, but that is not a substitute for a technical specification that relates the customer requirements to development requirements, factory controls, data security, color management and other processing realities. The customer has to be brought along for the ride to make sure that the tech spec ends up accurately reflecting the job to be done. Assuming that the documentation is created appropriately, the next problem is making sure that it is maintained as change requests and bug-fixes naturally occur over time. This can be a make-or-break situation with a contract dispute and can also lead to lost business if a future redesign is considered. Finally, documentation has a role to play in the testing process.

Testing

Sometimes customers want more time to do acceptance testing than they want to give your team to do the development in the first place! Project plans need to be clear about your internal testing time versus User Acceptance Testing (UAT) and who is responsible for generating use-cases for testing and providing test data. I will get into more about testing challenges in a future post.

Development Resources

You need to be realistic about how many projects your developers can reasonably take on at once. It is incredibly difficult to switch gears between multiple new development projects as well as change orders and troubleshooting for existing customers. There is also the challenge that some developers at printing companies have never developed an application from the ground up. There are more “maintenance” programmers out there than architects. Also, developers are not all interchangeable. Some may be really good with the data side of the equation where others are good with your composition  or color management software.  You can do some cross-training, but if they are all busy that will only take you so far. Ideally, you should have a strong list of contract resources available to fill the gaps. You may use them as experts to review estimates or the technical architecture of a new project  or to help create estimating standards. Also consider contract business analysts to help develop and maintain documentation.

Less Stress. More Profit

If you find yourself wondering if it’s good news when you win new business, it’s time to think about putting the mechanics in place to protect profits. With labor, particularly technical resources, increasingly difficult to attract and maintain you need to protect those assets as well.  Here are some things to consider:

• Understand the development tradeoffs between time, cost, quality - just like your print estimates
• Balance time to onboard print with maintainability of code and quality of result
• Investigate tools for making your onboarding process easier for customers and your developers (standardized code, templates, onboarding tools, conversion tools)
• Create standards to streamline estimating so developers can focus on developing
• Develop and MAINTAIN documentation
• Make sure you understand, and are prepared to support, the assumptions your developers make
• Understand the (common) limitations of development teams in general, and yours specifically
• Maintain relationships with contractors (and software suppliers) and use them on a regular basis

If the challenges I have described sound familiar they can easily feel overwhelming. But you can get a little better all the time.