Having appropriate processes, skills, and tools is not sufficient to achieve efficiency and effectiveness. Why? Because they do not directly motivate people. Motivation is a simple yet tricky concept. The leading motivation theory is Victor Vroom's expectancy theory. It has been proved remarkably consistent with observations, at least in Western culture (motivation is culture-dependent).

Expectancy theory: The strength of a tendency to act in a certain way depends on the strength of an expectation that the act will be followed by a given outcome and on the attractiveness of that outcome to the individual.
- S. P. Robbins, Organizational Behavior, 11th edition

The principles of the expectancy theory are straightforward:

1. Effort will be recognized in performance appraisal. It's not, for example, if I achieve challenging objectives but no one notices it.
2. A good performance appraisal will lead to organizational rewards. It doesn't, for example, if I get a good performance appraisal but there is never any money/training/promotion/[name your reward] left for me.
3. Rewards will be personally attractive. They're not, for example, if I get a raise and more responsibility when all I want is to spend more time with my family. (Michael Wade wrote an eloquent post about what people are looking for in the workplace)

(I have yet to find a company where managers understand these three relationships.)

You might think that this stuff is just for HR and top management. You're wrong. In most organizations, employees at all levels have the power to influence the performance-reward process. I am really fed up with whiners who complain about not being respected or about the managers not knowing anything but who never voice their opinion. The design and efficiency of the performance-reward system is everyone's responsibility!

Additionally, the system can work at all levels. Team leaders, project managers, business unit managers, and so on, all have power over some factors of the performance-reward system, such as performance appraisal, training, projects people work on, and roles. In other words, many people beside managers are ? knowingly or not ? involved in the system. Given the impact of the performance-reward system on motivation, and the impact of motivation on, well, everything (success, atmosphere, etc.), it's worthwhile for each of us to take a few minutes to think about how we can help making it better in our organization.

At last I have some time to write about some interesting topics that require some research. I noticed that auditing the software development practices is vastly misunderstood. Some think it deals with accounting software whereas others think it's about programming guidelines. It is neither. It is a relatively new discipline, but I suspect that many IT managers, consultants, and project managers have already been wrestling with it. I will use my experience, combined with some research, to help formalize the software development audit process. So expect a few more posts about this hot topic!

Let's start at the beginning.

The purpose of a software development (SD) audit is to assess SD practices in the target organization and to recommend improvements to help the organization achieve its business objectives. Although the scope of an SD audit can vary, it typically encompasses SD processes, organizational structure, tools and technologies. In essence, the goal of the SD audit is to optimize SD's effectiveness and efficiency.

Note that an SD audit is not an IT audit. Although there is some overlap, the IT audit deals primarily with IT operations.

[EDIT 24 Nov 2008] A Practical Guide to Auditing the Software Development Process is now available.

It's worth clarifying the definition of these two words:

• Effectiveness: doing the right things
• Efficiency: doing things right

Both are necessary to achieve success. Effectiveness is associated with leadership whereas efficiency is associate with management.

This is a follow-up on the post IT projects and client communications.

In a previous post I mentioned the Client Communication Plan (CCP), which is part of the project charter (or contract with the client). The purpose of planning communications with the client is to make the client comfortable and pre-empt questions.

In any project, we can easily identify when we have to interact with the client. Event such as milestone approval, requirements gathering, and so on, can be planned. Each event is associated with a responsible person and a deadline. The CCP also helps motivate the team by providing intermediate deadlines. Indeed, demonstrating a feature to the client in order to validate the work done, for example, is much more motivating than an internal review done by testers.

The table below shows what a very simple CCP might look like.

Note that although we explicitly plan interactions with the client, we do not disclose any information about the internal workings of the team. Things such as methodology, iterations, tasks, and so on, should remain hidden from the client. Why? Because too much information is just as bad as too little. With a view on inner workings, the client will be compelled to ask unnecessary questions. In other words, the client has to be aware of what we do, expressed in his own language, but not how we do it.

You might be surprised how a simple tool such as the CCP makes project development easier for everyone!

I felt it was a good idea to summarize the advantages and disadvantages of SaaS from customers and suppliers points of view. This list is by no means exhaustive but will hopefully give you a brief overview of the impact of SaaS from a business (not technical) standpoint.

Wikipedia defines SaaS as: [extract]

Software as a service (SaaS, typically pronounced 'sass') is a model of software deployment where an application is hosted as a service provided to customers across the Internet. [...]The SaaS software vendor may host the application on its own web server, or this function may be handled by a third-party application service provider (ASP).

Advantages for customers

• Lower cost: Most customers prefer a continuous expense than an up-front purchase. However, it has tax consequences since an expense is a period expense whereas a license, for example, can be capitalized as an asset and then depreciated over time. But more importantly, SaaS is on-demand, which means that the customer pays for what he uses (pricing is usually expressed in "service units"), no more, no less. The on-demand model usually translates into cost savings because the use of a service changes over time and because the customer does not manage the solution's complexity (see below).
• Deployment: the customer does not have to go though potentially complicated hardware and software requirements. A simple interface such as a web browser or a thin client will allow using the services with minimal deployment.
• Scalability: As mentioned above, the use of a service changes over time, and can seldom be forecasted. Imagine for example a SaaS accounting system. The system is used much more intensely when closing an accounting period than in normal times. The SaaS services can be automatically scaled according to the actual demand. Same applies if the company grows or shrinks: the SaaS services can be easily down-scaled or up-scaled.
• Outsourcing IT concerns: Similarly to traditional outsourcing, SaaS allows customer to avoid managing the complexity of an IT system, such as licenses, hardware, or upgrades, and focus on their core business.

The following chart shows typical reasons customers mention for adopting SaaS.

Reasons for adopting SaaS (source: Formtek blog)

Disadvantages for customers

• Lock-in: SaaS vendor often rely on proprietary solutions that lack portability. Additionally, SaaS contracts will prevent customers to quickly switch supplier. For this reason, the choice of a SaaS supplier is an important decision, and the price should not be the only deciding factor.
• Lack of control, security: With the SaaS model, applications and data sit at the supplier side (i.e. server-side). Just like for outsourcing, remember the golden rule: don't externalize what makes your competitive advantage. I personally advise not to move strategic processes and data to SaaS, at least not before testing the SaaS supplier extensively.
• Lack of flexibility: SaaS solutions might be scalable, but since a single server-side instance can serve multiple users/customers, the ability to customize the solution for an individual customer/user is limited. For this reason, you might want to avoid SaaS if you have needs that are very specific compared to average industry needs.
• One more supplier: You certainly know how frustrating it is to solve a problem when it implies multiple suppliers. With a SaaS provider, possibly an ASP in-between, a software provider, and your local IT system, locating the cause of a problem can be more daunting than actually solving it. The SaaS supplier will be one more supplier, and you'd better make it clear who's responsible for what before you sign any contract if you don't want to spend hours listening to Mozart over the phone when a problem arises.

Advantages for suppliers

• Revenue stream: Just like SaaS is a period expense for the customer, it turns customers into flows of revenues for the supplier. It makes for a smoother cash-flow and better predictability.
• Control over intellectual property: With SaaS, suppliers retain ownership of the software, and know exactly where, when, and how it's run. This solves in effect most intellectual property concerns that hurt (or even cripple) traditional software vendors.
• Customer retention: The lock-in problem mentioned earlier can be seen as a customer retention mechanism for the supplier. The customer will stay unless significantly unsatisfied, and even then, breaking the contract will probably take a couple of months. Of course, it is not a good kind of customer retention and will not do for the long term.
• Sales and distribution: Bypassing intermediaries such as wholesalers, distributors, and retailers, makes sales an distribution leaner. It also allows the supplier to be in direct contact with customers and discover new opportunities.

Disadvantages for suppliers

• Responsibility for customer data: Being entrusted with potentially critical customer applications and data implies responsibility. SaaS vendors will pay dearly for any service failure. This is the flipside of all the advantages of this model. After all, you cannot have power without responsibility. I would not be surprised to see high-profile failures in the next years as the SaaS model matures.
• Support: Because the customer relinquished control to the SaaS supplier, the supplier becomes responsible for supporting the applications he serves. The complexity of support for customized business applications should not be underestimated. I expect this will be a major differentiating factor for SaaS vendors. Only the suppliers with excellent support will be able to tap into the lucrative market of critical business applications such as ERP and CRM. Others will be restricted to non-critical applications such as email and knowledge bases.

Conclusion

I believe that, in the current state, SaaS is appropriate only for non-strategic, commodity services. I would wait until the SaaS model matures and vendors prove their abilities before running critical applications in SaaS.

Additionally, I believe that SaaS makes more sense for SMBs than for larger organizations. Indeed, it allows SMBs to use applications that they could not afford otherwise because of the costs involved (license, deployment, in-house support, etc.).

Sources:

• Software as a Service (Wikipedia)
• The Maturation Process of SaaS Support (Jeff Kaplan, Think IT Services, 2008)
• Sussing out SaaS (ITBusiness.ca, 2006)
• SMB SaaS sales robust, but holdouts remain (ComputerWeekly, 2007)