Software Best Practices

We want to be some more profitable than our competitors, building on expertise, efficiency and readiness to changes. I think that a management effort in this sense will bring us more possibilities to succeed.

Marco

Hello Marco,

What an interesting question! Profit, is of course, the difference between cost to produce and price charged. In reality, the developers have little control over profit since they have NO control over price charged. What I guess you are asking is what is the best way to lower cost since if the developers have any control, it would be over the cost to produce.

Now cost to produce is directly related to effort. Barry Boehm's research for COCOMO has identified some 22 parameters that impact the effort to produce software. Five of those impact effort exponentially, seventeen linearly. If you review the factors, many of them our outside the control of the developers themselves (e.g. if there is a desired schedule compression).

So what do the developers have control over to help lower cost. As a foundation, each development must have good fundamental development skills and work continuously on improving them. If you have that, I find there are some core things can directly impact cost.

1. They have the ability to accurately estimate the development effort. Mistakes here quickly drive up costs and not allow the sales folks to price things correctly.
2. They have the ability to help the customer create accurate and well refined requirements. We can't spend time building the wrong things.
3. The ability to select a development approach the best suites the current project. We need the methods to aid us, not hinder us.

I think this is where developers can be more responsible for project profitability.

Earl,

 Here is one more to your accurate list of how developers can contribute towards profitability:

4. They flag dependencies not met by the customer as early as possible and detect subtle changes to features that customer representatives in charge of the software development typically demand. These can be revenue generators too in the form of change requests.

 Often I've seen (and been frustrated as management usually is) that someone with the right intent of treating customer as god continued to wait even though the time meter had started ticking on a dependency. Or worse agreed to a subtle change without informing the Project Manager.

Its not just effort that drives profitability it can also be contractual penalties for dates missed for fixed-price projects. So its important to track client-side dependencies and the best way to do that is to educate and empower developers about the key technical ones.

Regards

Arun N. Swamy 

I agree, I'm often amazed at how customers often appear to assume that they are never on the critical path for the project.  I have worked for one company that was very good at presenting, pre-sale, a timeline with all customer/supplier dependencies clearly marked and was generally able (mainly due to having some very technically competent sales folks) to make these contractual.  I mean contractual in the sense that the contract documents clearly indicated how delays on customer deliverables would affect the project milestones, and in some cases costs.

Unfortunately, however, I've also worked for four three other companies which are not very good at this, or indeed choose not to do this so as 'not to scare the horses'.

Keith

We have seen many companies struggle with this question. I think most developers will need to work for at least a few years before they're even ready to think about general business issues, much less profitability. They need to spend those first few years learning how to work in a commercial setting, learning how to write production (as opposed to academic) code, learning the subject area, and so on.

After a few years some of them will become ready to develop some "business awareness." Of course this is not the same thing as being "responsible for profitability," but I don't see how you can achieve the latter without achieving the former. I think there's a largely undocumented best practice for helping developers develop business awareness, and that is supervised direct customer contact. I can't even tell you how many companies we've worked with that have raved about the positive effects of putting their developers in direct contact with their customers. For example, sending them out on field support calls for a week, sending them along on sales calls several times over a quarter, having them staff a technical support phone line for a few days, and so on.

What you typically see when this happens is that developers change their mindsets from "the users are so stupid" to "hey, the users' environment isn't like that! They need it to work *this* way!" This has an indirect positive impact on profitability for a couple of reasons: (1) As Earl Beede mentioned, they understand the implied requirements better, and so there are fewer false starts in requirements, (2) they learn that there are lots of really complex, hairy features that the technical staff might find cool but that would be unusable to the customers, (3) it opens up ongoing communication between the developers and the customers/users.

The main hazard to watch out for is developers making feature commitments or date commitments or other kinds of commitments to customers by mistake. The developer might say, "Oh that's easy to do," which is just a technical judgment that, "that's easy to do." But the customer might hear, "That's easy to do, therefore we'lll do it." So you have to coach developers ahead of time about not making commitments by mistake!

Aside from greater customer understanding .... I don't think it's ever going to work very well to make developers very directly responsible for project profitability. But I think the company management can help by making the project goals and priorities crystal clear to the dev staff -- e.g., "We're getting an on-time completion bonus on this project, so if it comes down to 'polish the feature a little more' vs. 'do the simplest thing that will work', we need to do the simplest thing that will work." Management is often guilty of being wishy washy about project goals, and defining everything a goal ("make it better, faster, AND cheaper") is essentially the same as defining no goals.

Beyond that, I don't think making developers directly responsible for project profitability is any more workable than making managers directly responsible for technical quality. Of course managers can influence the outcome to some degree, but they can't be directly responsible for it. Similarly, developers certainly have a role to play in affecting project profitability, but other people (i.e., managers) have to play their roles, too, and their roles are going to have a greater impact on profitability.

Bottom line, I think the answer is (1) state project goals clearly (in project-level terms that developers can understand), (2) continue to "message" these goals over the course of the project so that everyone knows you really mean them, (3) align performance reviews and other rewards with the stated goals, (4) give technical staff exposure to the customers/users so that they'll guess right more often.

Earl and Steve point out the difficulties of making developers directly responsible for profitability.

That is true, but that doesn't mean you cannot help them be indirectly responsible for profitability. The key is clearly defining what makes you profitable - this is a difficult challenge.

One example, that I hope nobody emulates, came from a body shop I once worked in (before I joined Construx).  Their measure was the number billable hours.   While this helped the body shop's bottom line - it certainly didn't help build customer value.

I heard a much better example from an attendee at our Executive Summit a few years ago.  His company was a service provider whose revenue was based on the number of transactions they processed.  In the developer space, they had a monitor that tracked the number of transactions each day, and the threshold they needed to reach to generate a profit each day.  When they released an update, the developers looked to the monitors to see how their work increased the transaction rate.  Through the monitors, the company provided a clear message of what was important.

Going back to Marco's original post, he stated their goals as:

We want to be some more profitable than our competitors, building on expertise, efficiency and readiness to changes. I think that a management effort in this sense will bring us more possibilities to succeed.

If this is the case, then Marco's difficult challenge is defining measures for each goal.  Off the top of my head, here are some examples to consider:

• More profitable - Revenue per full time equivalent, Profit Margin per project, Average cost per ERP Rollout
• Building on expertise -  Training time, Project setup time, Communications Overhead time
• Efficiency - Effort hours per feature, Effort hours per ERP rollout
• Readiness to change - Time to respond to change, Average cost per function to upgrade

I'm sure you get the picture. For more information on defining measures, I recommend you read Tom Gilb's Competitive Engineering (Butterworht-Heineman, 2005)

Jerry Deville:

In the developer space, they had a monitor that tracked the number of transactions each day, and the threshold they needed to reach to generate a profit each day.  When they released an update, the developers looked to the monitors to see how their work increased the transaction rate.  Through the monitors, the company provided a clear message of what was important.

Jerry's example is interesting. I'm also familiar with the company he's describing. The connection between the developer's actions and the transaction rate was pretty indirect. Considered from a pure software engineering measurement viewpoint, the measure was weak. On the other hand, the fact that it was so readily visible made up for some of the weakness. Since the monitors were constantly visible, people could just look at them and say, "Hey look our transactions are up today. Maybe that's because of the programming change we just made." They might ultimately conclude that the transactions were up for some other reason, but the high visibility of the measure supported at least having a discussion about it.

In terms of the original question about making developers more aware of profitability, having even a weakly-connected measure displayed on the monitors helped regardless of how meaningful the measure was because it reminded the developers that their work had an impact on the company's financial performance and got them talking about it. In other words, it raised their consciousness of the business impact of their work.

I was thinking of making public for my employees some indicator like our rate of overdue balances, every week. It is not a direct indicator but quite good to point out what are major problems. I like this indicator more than billable hours because it is more related to customer value. Billable hours are also a benchmark that we use for some consultants, as a way to rewards those who are more present at customer sites. You gave me a lot to think of, expecially for our new round of process improvment to manage ERP projects. Thanks!

M.
 

Here at NEC Telecom Software Philippines, Inc., project leaders aren't concerned with profitability but rather with costs in terms of person hours.  We do business via fixed-price contracts and obviously we lose money when we spend more time than alloted.  We meet our profit margins if we deliver on time while working within planned hours, and we make more if we deliver earlier (assuming there are no post-release bugs which translates to rework hours) without overtime hours.

Efforts like those outlined above, e.g., clearer or at least managed requirements, better estimates, the right resources at the right time, better tools, all directly impact profitability even if developers don't think about 'profits.'  I for one, don't believe that developers need to understand project finance or things like activity-based costing but I do agree with Steve that they should be business-aware, i.e., Why we are doing what we are doing? How do we make money?  How do we lose money? -> A simple flow chart would do.