Consulting missions often involve designing or adapting processes in the target organisation. However, the fact that processes will be affected is not obvious at first, because we tend to start the mission with a predefined conception of the solution that stems from our area of expertise. Being primarily in IT, I tend to "see" IT-based solutions to every problem. But if we force ourselves to take a broader look at the problem, we discover that it is rooted in multiple processes and that the solution requires affecting these processes, not just IT. I believe specialists have a lot to gain from integrating process analysis in their consulting approach. Note that I do not advise to use only process analysis (read also my post on people-centric processes).

The 6 main steps of process design are:

1. Define the mission scope: elicit measurable objectives, identify stakeholders, and identify levers (also read my post on defining a consulting mission).
2. Perform value stream mapping (or value chain analysis), in both bottom-up (perception of people actually doing the work), and top-down (people managing the process/functional areas) approaches.
3. In parallel with step 2, change the mindset of people by questioning what they're doing, why and how they're doing it. In other words, foster a TQM or kaizen mindset across the organisation.
4. Identify potential improvements and estimate their ROI.
5. Together with stakeholders, prioritize improvements according to their ROI, objectives, and constraints (such as resources). Improvements involve process and organisational changes. This takes the form of a transition plan.
6. Coach the transition and assess results continuously to adjust the transition plan.

A few words on standards and tools. The most popular notation to describe business processes is BPMN (Business Process Modeling Notation). The emerging format to represent BPMN descriptions is XPDL (XML Process Definition Language). A number of tools are available to design BPMN with XPDL file format. One of them is the Eclipse BPMN Modeler, a plug-in for the Eclipse platform (free and open source). Another interesting resource is the Process Wiki, which hosts an exhaustive collection of business processes.

Earned value management (EVM) combines the measurement of scope, schedule, and cost in a single technique. EVM helps bridge the gap between agile project management and management metrics, by defining variances that provides accurate project status for scope (corresponding to the value of what has/will be delivered), cost (both budgeted and actual), and schedule.

The variances measure how the project is doing relatively to these three dimensions of progress. A single variance will leave part of the truth out of the picture; therefore we have to look at multiple variances to get an accurate status.

Let me give you an example: a project is made of three tasks of identical value and cost. At a specific point in time, the schedule tells us that tasks 1 and 2 should have been completed. But only task 1 has been completed, therefore the project is behind schedule. However, the actual cost of work performed (i.e. for task 1 only) is lower than the budgeted cost of task 1, therefore the project is under-budget. Consequently, the project is late but cost less than expected to deliver this value. One typical explanation of such a situation would be that part of the team has been allocated to another project after initial planning, but that the remaining members of the team worked more efficiently than planned (probably because of the pressure of the project being late).

Anyone involved in projects can understand why EVM is useful, but what does it have to do with agile?

Remember that one of the founding principles of agile is that progress is measured in delivered value. EVM, as the name implies, also focuses on delivered value. But measuring value the agile way is overly simplistic and can lead to misinterpretation of the status. In Scrum for example, the burndown chart pictures delivered value over the project and during the current iteration. If you already used this technique you certainly felt that something is missing. Indeed, by moving items in and out of the product backlog in the middle of iterations we loose the ability to evaluate how the project is doing according to schedule. Similarly, the burndown chart assumes that an hour of work accurately reflects all costs, failing to reflect that different team members incur different costs, as well as other costs. Therefore the information we have prevents us from using the variances defined by EVM.

Agile methods fit perfectly with EVM in principles but fail to provide techniques to measure variances. This is one of the reasons that agile has so much trouble gaining acceptance among managers and remains confined in small-to-medium development teams (in most organizations). The vast majority of agile "project managers" (excuse the quotes) do not know how to communicate to manager types how the project is doing according to schedule and budget (or maybe there is no schedule or budget because, you know, we're agile now).

Some hard-core agile advocates might perceive EVM has an "old school" technique that would make agile less agile, but I frankly do not see how you could measure progress without adding some metrics to agile-as-it-is-now. EVM has the advantage of being simple enough to add very little project management overhead, while providing true management-level metrics.

Other practitioners share this opinions:

• Dan Rawsthorne, Calculating Earned Business Value For An Agile Project (2007), Agile Journal
• T. Sulaiman, B. Barton, T. Blackburn, AgileEVM - Earned Value Management in Scrum Projects, SolutionsIQ
• A. Cabri, M. Griffiths, Earned Value and Agile Reporting, Quadrus Development Inc.

Innovators, whether they are individuals or organizations, tend to try producing and bringing their innovations to the market by themselves. In many situations, it may not be the best option.

There are several ways of commercializing innovations, separated in four categories in increasing order of innovator control:

1. Sell design: It requires market proof but allows earning a lump sum of money. It prevents the innovator from exploiting his innovation in the future. Pure inventors often rely on this option because they focus exclusively on R&D and do not want to be involved in marketing, production and distribution.
2. License: The innovator sells the right to use the technology, to an OEM form example. The innovator looses control over his innovation but can get a steady stream of income. Licensing deals vary greatly according to the negotiation power of parties. Licensing is an option only if the innovation has been tested in the market.
3. Joint venture: The innovator partners with other companies to handle processes such as manufacturing and distribution. Depending on the deal, the innovator might be a minority partner or not. Brand ownership is often a determining factor of the deal.
4. Produce and market: It requires a lot of skills and resources, and the costs incur long before generating revenues. Only companies with deep pockets can afford to go all the way from R&D to market. In the other hand, it is the only way to reap the full benefits and to retain control of the innovation.

The conflict is a process that begins when one party perceives that another party has negatively affected something that the first party cares about. Whether the conflict is good or bad depends on the type of conflict. Functional conflicts are constructive; they support the goals of the group and improve its performance. On the other hand, dysfunctional conflicts are destructive and hinder group performance.

The conflict process comprises five stages. The first stage is potential opposition or incompatibility. It creates an opportunity for the conflict to arise. At the second stage, cognition and personalization, parties perceive that there is a conflict but no behavior is apparent yet. In the third stage, parties develop intentions about how to handle the conflicts, such as competing, cooperating, or avoiding. The fourth stage, behavior, is the stage that we usually see as the conflict itself for this is when the conflict becomes visible. The fifth and last stage is the outcome, which might increase group performance (functional conflict) or decrease group performance (dysfunctional conflict).

There are several ways to resolve conflicts, of which problem solving is the most common. It involves face to face meetings of the conflicting parties for the purpose of identifying the problem and resolving it through open discussion. We will describe a typical resolution of a dysfunctional conflict through problem solving, based on my personal experience.

Since two weeks, Mitch is consistently late with the tasks he's accountable for. It seems that he always encounters some "obstacle". Looking into it, I noticed that he could have solved most of these issues by himself; he definitely didn't try very hard. For those he couldn't, he could have found another way to contribute to the project instead of waiting idly till the next daily meeting. At daily meetings I could tell that other team members were starting to see Mitch as a fifth wheel.

Mitch and the rest of team ? which I'm part of ? have a conflict. As project manager, it is part of my role to resolve the conflict.

Mitch is part of my team since only one month, but is working with the company for the last 2 years. I decide to talk for a few minutes privately to his former project manager. She mentions that Mitch was never a star, but delivered decent results. If I fail to solve this conflict, Mitch will have to leave the team, possibly even the company. Since he has the skills and proved a decent worker before, I would see that as a personal failure. It is my job to bring him back on board and unlock his potential.

I have to talk to Mitch privately. Having this discussion publicly might humiliate him. I ask him when we could have a 30 minutes discussion, and I choose a small meeting room as the location. I could have chosen my office, but a meeting room is better as neutral territory.

The next day we meet in the small room as planned. I tell him what I noticed, and why it troubles me. I briefly go though facts but never show anger. Rather, I show disappointment. I don't mention anyone else: I am the one making the observations and I am the one having an issue with his behavior. I then clearly mention that my goal is to help, that he's a skilled and experienced professional and that we need him on the project. Note that, even if I had received information from someone else, mentioning this third party would instantly broaden the conflict and turn it into something personal.

Now comes the time for me to listen in order to understand the underlying cause of the problem. Mitch clearly dislikes what he's working on. "It's this new CMS", he tells me, "I'm a graphic designer and I'm working on this thing since two months because I'm the only one who knows how to use it!" I know that Mitch is a graphic designer. From the start we agreed that he would work temporarily with this new CMS. But I couldn't imagine that he would come to dislike it to this point.

I tell Mitch that he should have been more proactive instead of letting the situation degrade until it affects his mood and the whole project. I also tell Mitch that we have to find a solution. The project is scheduled to be finished in 6 weeks, and until then we do not have any other choice but to rely on this CMS. I clearly tell Mitch that I will make sure that he will resume his graphic designer role after the project. I ask Mitch if he agrees on that. He does, but I can see he is somewhat reluctant to trust me. I tell Mitch that I will look into the next projects to find a role that better suits him. I add that, if it's impossible, then I'll consider transferring him to another team. I ask him once more if he's ok with that. Mitch seems to trust that I'm really looking for a solution now. I immediately schedule another short meeting, next week, to follow up on what we said, so that I can tell him the result of my investigation and give him a feedback on his performance (since he's supposed to beef up his effort). I'm happy with the negotiation too. I removed any possible excuse for Mitch to do sloppy work, which should put the project back on track.

We can easily summarize the problem solving steps:

1. Formulate desired outcome
2. Research antecedents
3. Set place and time for negotiation
4. Tell what I have observed
5. Listen to gain better understanding
6. State my needs clearly
7. Agree on a way to solve the problem
8. Follow up thoroughly

The theory part of this post is heavily inspired by the excellent book Organizational Behavior, S. P. Robbins, Prentice Hall.

There is a lot of confusion about how software-as-a-service (SaaS) relates to cloud computing.

Although both can be somewhat defined according to technological and business perspectives, SaaS is best characterized as a business model for delivering and deploying software applications, whereas cloud computing is a general concept based on the abstraction of infrastructure. Therefore, cloud computing encompasses SaaS, although I would rather say that SaaS relies on cloud computing.

Wikipedia defines cloud computing as [extract]:

The cloud is a metaphor for the Internet, based on how it is depicted in computer network diagrams, and is an abstraction for the complex infrastructure it conceals. [...] Cloud computing is a general concept that incorporates software as a service (SaaS), Web 2.0 and other recent, well-known technology trends, in which the common theme is reliance on the Internet for satisfying the computing needs of the users.