ThoughtFactory.CreateThought() A random collection of thoughts from an easily bored developer

Lip Service

The internet is a fast paced world where the general consensus about what is "cool" can change in instant, and the online software development community is no exception. Recent years have seen movements relating to topics such as craftsmanship, quality, and design spread like wildfire through the tubes, eventually crossing over into the real world in the forms such as books, conference talks and user group meetings.

If consulting companies are good at anything, it's recognising trends and jumping onto band wagons. Many organisations have seen the movements within the development community as opportunities to gain new business, attract employees or quite simply make some cash. Others are staffed by people who are not quite "in the loop" enough to be part of the original movement but still want to be seen as participating even if they don't understand the finer details of what those wacky internet people are talking about. This has seen a large number of IT consulting firms attempting to align themselves with a wide range of topics/buzzwords such as Agile, TDD and SOA.

This alignment process has lead to a rather disturbing trend of companies making bold statements about the "minimum standards" that their teams must adhere to. I use the word "disturbing" for two reasons:

1. The minimum standards are usually ill-conceived or miss the core principles of what the original movement was trying to say
2. When push comes to shove, they are not actually enforceable, leading to uneven application or even complete abandonment of the "standards" dependent on client or project

Consulting firms have been missing the point in an attempt to "me too" the latest trend, so no surprises with the first point; just ask for a definition of Cloud Computing next time you're at an industry conference to see that in action.Still, in some cases there is still some value to be gained out of the application of the misinterpreted principle. After all, the Code Reviews touted by a firm may be nothing more than a soulless checklist designed to cover behinds rather than improve code quality, but at least it's a start.

Now, setting aside that what these companies are trying to implement isn't all that great in the first place, it's still amusing that there seems to be a huge lack of understanding around the  meaning of the word "minimum". If you're having trouble, let me Google that for you. If you have a set of standards, then say that a certain set of those standards is the minimum that you will apply then those are the smallest set of standards that must be met. In fact, it should mean that a project crisis meeting is held or intervention is required if you don't actually meet those standards. If a standard is not enforceable, or you don't apply them in specific circumstances then it is not a part of your minimum standards; you may wish to refer to it as a "nice to have".

I have a sneaking suspicion that both of these points are inherently linked; companies are keen to ditch their principles at the first sign of trouble simply because they do not see value in them, and the reason they do not see value is because they fundamentally misunderstand the reason for doing it in the first place. Take TDD, for instance.  If you tell someone that they have to write tests for the sake of writing tests, and don't have a discussion or opinion about test-first or TDD as a design activity then they're probably not going to get any real value out of the activity. It will be seen as extra work with no pay off, and eventually people will start to avoid writing tests like the plague. The lip service approach just isn't enough to convince people to change their principles and values, at least not in the long term.

If you work for a company like this, it's important to realise that all is not lost. Someone above you in the organisational chart thought that the standards and principles were important enough to write up a PowerPoint presentation on, and maybe even paid for some basic training. They see a value in it (be it  a cultural alignment with their own beliefs, a financial benefit or something else), but for whatever reason they just don't properly understand what the end product should look like. If you see a topic that is near and dear to your heart being butchered by your employer, find the person who is doing the butchering and help them understand. Explain what the concept is really about, and what the real benefits are. Even if they just want to ride the buzz word wave all the way to the bank, they still want to see it succeed, leaving you with an opportunity to nudge the ship in the right direction.

Consulting Contracts for Developers 101

If you're a developer that works for a consulting firm, chances are you've never really thought about the contract that you're working under. Managers can take care of all that stuff while you look after important things like shipping features to users, right? Well, not exactly.

Before we get to that, let's define exactly who we're talking about. Generally, you're a consultant if:

• You work for a consulting firm (obviously)
• Something other than your time is being sold to a client

You're not a consultant if:

• You work directly for the client
• You're a contractor working for the client either directly through a specific contract or indirectly through a proxy such as a human resources company and the contract solely relates to the customer buying your time

Now that we've got that out of the way, what do I mean by "something other than your time is being sold to a client"? Well, consulting companies make their money by taking what you do and reselling it to a client with some sort of value-add on top. Different companies have different offerings and different "value-add" that they sell on top, and clients will pay a varying premium depending on the specific nature of these services. The important thing to note is that when a customer engages with one of these consulting companies, there is an expectation that they will get something a little more than 8 hours a day of a developer's time. After all, they are paying a premium.

These extras that the client is paying a premium for can take the form of something tangible, such as methodologies, templates or software assets, or something intangible like access to a staffed bench so that the client doesn't have to go to market to hire new developers. it can even include access to additional services like architectural reviews or research and development centres that can provide advice and knowledge on specific topics. In fact, it may even be something as simple as getting access to developers that have a guaranteed level of training and experience and are involved in a monitored continual improvement program. Whatever it is being offered, it's important to realise exactly which one of these extras the client is expecting from you.

Some of these extras may be implied and not contractually enforced; for example getting access to a consulting firm's bench is something that a client would just take for granted, and it makes it's money back through the fact that the developer is able to start sooner than going directly to the job market. Same goes for getting access to highly skilled staff. This premium would be earned through reputation and referenceability, and justified by continual high performance at a client site. It's still good to know what the client expects so that you can manage those expectations at a personal level. Hopefully no professional consultancy would sell you onto a client gig under false pretenses, but it's always good to know in advance that the client expects you to be an Oracle Forms 3.0 expert even through you were still in Grade 2 when the product was originally released. At least it would give you time to browse job sites for a job with a more ethical firm.

Where it gets interesting is when the extras are contractually enforced. When the consulting company and the client agree to work together, in most cases they'll come to some sort of agreement as to how that engagement will work. There are some tangible extras that can be thrown into these contracts, especially in the case of methodology and assets. As a developer on a project you want to make doubly sure that you're not, for example, using company IP to develop a solution for a customer when they don't have a licence for it, meaning rework and additional cost. The part of the contract that makes the most difference to a developer's life, however, is how the work itself is packaged.

Work can be packaged in a number of ways:

• Fixed Price
• Time and Materials

In both of these scenarios it is vitally important that the development team continue to feed back accurate information about estimates, risks, issues, potential functional gaps and anything that may affect cost. Regardless of how the customer wishes to pay, the customer is still paying and needs to know what they are getting. As a developer doing the work you should be taking responsibility for at the very least reporting back up the chain of command whenever something isn't going as expected.

One thing to note: I talk a lot about the behaviours that these contracts can drive. I don't necessarily mean that this is exactly how either party will behave if this contract is used; it's more that there's an advantage to one of the parties if that behaviour manifests itself. Most reputable clients and firms would hopefully not engage in such behaviour, although stranger things have been known to happen. It is important for developers to recognise the potential impact of these behaviours and watch for any signs that they may be occurring. Once a problem is recognised it can be dealt with, but the first step is admitting that there is a problem.

Fixed Price

Fixed Price engagements are exactly that; customers agree to pay the consulting firm a fixed fee for a specific service. The nature of this service depends on the contract. These deals usually have a contingency clause built in that allows the consulting firm to draw down on extra money if certain conditions are met. It is important for senior members of the development team to be aware of what these conditions are and know when to identify the need to use this extra money to their Project Manager.

The attraction of Fixed Price engagements for a consulting company is that they stand to make a lot of money if they deliver to the terms of the contract by spending less money than they originally thought. The risk is that if it costs the consulting company more money to deliver on the agreement then they stand to lose money on the deal. The attraction to the client is that there is a known amount of money that they will pay for the agreed service, with the risk being that they may pay more than is necessary for the agreed services.

Exactly what is being delivered for the fixed price varies, but can generally customers would be signing up for either agreed deliverables and functionality or a fixed amount of time (say 500 hours of a Senior Consultant's time). The former is usually referred to as "Fixed Scope" and the latter as "Variable Scope".

Fixed Scope projects are often associated with the words "change request". Anything that the customer wishes to do that was not agreed upon up front must by added to the scope by applying a change request on top of the original proposal. Developers need to be aware of this, especially if there were plans to run a project in a remotely agile manner as the constant administrative overhead of agreeing on change requests for every new feature can make it easier to opt for a more up-front development methodology. This may not necessarily be pure waterfall, but it may involve coming up with initial high level requirements for the entire system and including enough room in the estimates to be able to accommodate slight variations in requirements as part of an iterative development process. All architects, team leads and senior developers on the team should be across the change request process so they can identify functional variances early on.

Developers must also be keenly aware that they are contractually obligated to provide the required scope, regardless of whether the customer actually needs it. That means that if the customer no longer needs feature X which was included in the original scope then this should be identified and change requested out of scope. There's nothing worse than a customer refusing to pay because you failed to meet contractual terms even though you met their functional needs.

Senior delivery team members will also need to be cognizant of where the money for change requests is coming from; some projects may simply use the contingency money to pay for any change requests and have no ability to pay for extras once that money is gone, while others may be able to go back and request additional budget. This may not immediately seem like something the delivery team should be aware of, but being on the front line means that you are also the first ones to potentially make promises to the customer that cannot be met. Imagine telling a customer "don't worry, we can change request that feature in" when in reality the pot of gold set aside for change requests ran out in the last iteration. Not good.

Fixed Scope can lead to some strange behaviours in both client and consulting firm. If you think about it, the client has an incentive to get as much additional scope in under the radar, perhaps by classifying it as something that has already been agreed or by leaving a requirement sufficiently vague enough that they can push for additional features to meet it. It's in the consulting company's best interests to do the work as quickly and cheaply as possible, as the less it costs the more money they make. This could lead to corner cutting or arguments over scope that wouldn't happen if a contract with better incentives was used.

I've often found that customers who specifically ask for Fixed Price - Fixed Scope on their first engagement never end up asking for it again, as the change request process is so frustrating. Unfortunately the nature of this contractual mechanism means that customers can often end up with either an administrative headache or a system they don't want if the initial analysis isn't somewhere in the ballpark.

Variable Scope projects are significantly different, as effectively all  the customer is doing is pre-purchasing a block of time. There is no commitment from the consulting firm on the scope that will be delivered, but there is a commitment to provide a certain number of resources for a certain number of hours to do "stuff". Now, this might sound fantastic, but developers should realise that the customer still has expectations around what will be delivered, and there's still a fixed amount of cash available to do the work. Once that money is gone, if the project is not finished then you'll be in change request territory.

It's important to get a good idea of what the customer expects to be delivered for this money so that there are no surprises, and the team should obviously involve the customer in the development process so they are up to speed with how things are going. Saying that, the Variable Scope approach does allow for a more flexible requirements gathering process, and can support more agile methods if the customer is on board with the idea. The consulting firm can still get the "advantages" of Fixed Price by either delivering something the customer is happy with before the alloted time is up or using cheaper developers to do the work, and the client still knows that there's a maximum amount of money that they are going to shell out, even if they can't hold the consulting firm to any sort of agreed scope.

The behaviours driven by Variable Scope projects are not necessarily fantastic. It is in the customer's best interest to try and get the consulting firm to do as much work as possible during the allotted time. This can lead to massive scope creep and a generally unmanageable project, and funnily enough it can also lead to customers requesting that developers cut corners or quality in order to add additional functionality. This is especially true if the development team is obliged to fix any bugs introduced in agreed functionality; once you agree to built it in a shoddy fashion it doesn't mean that your agreed defect rate has suddenly changed. On the flip side, it is in the consulting firm's best interest to get the customer to agree that the project is finished as soon as possible, or to swap out all their key resources with cheaper ones.

Time and Materials

Time and Materials is the "pay as you go" approach to consulting. The client has a rate card or something similar detailing what each resource costs, and simply pays for the time that is used. These contracts generally come in two flavours: Uncapped and Capped.

Uncapped Time and Materials gigs are my favourite type of contract. Obviously there is the potential for the consulting firm to want to elongate the development process to milk more money out of the client, but this usually offset by the client now having some skin in the game from a financial perspective; if they can own the scope and take an active part in the delivery of the project then they will pay less. It's amazing how money can be a motivating factor, especially if the person who owns the budget is particularly close to the project. These projects are also generally the best vehicle through which to attempt a more agile project with less up front requirements gathering.  Once again, the customer must be on board with the process as it's their money that is being spent, but the freedom afforded by this type of contract means that developers can more easily adapt to implement features that are actually needed, and even abandon features that present no business value.

These Uncapped Time and Materials projects usually provide a great opportunity to make real improvements to a business, especially if the client is receptive to IT and change. You'll have a much better chance of getting someone to agree to ditching the 3 weeks worth of work you've already spent on Feature X to spend 6 weeks on an alternative solution that has greater business benefits if the change can happen at an iteration planning level rather than having to go all the way up through the PMO.

Capped Time and Materials contracts present no real "win" for a consulting firm. If they finish early then there is no bonus, and if they go over time then work simply stops and things often degenerate into a slanging match as there was no agreed scope that a customer can tie the development team to. Not exactly the healthiest way to end a project. Effectively a Capped Time and Materials gig is a Variable Scope Fixed Price engagement with no upside for the consulting firm.

With Capped Time and Materials, it's generally a good idea to do some sort of initial scoping as part of the project and start doing enough documentation to avoid any arguments about what is still left to implement when the money runs out. All members of the team need to be keenly aware of how they are tracking against estimates, and customer expectations need to be properly set at all times.

There are other contractual mechanisms through which a client can engage with a consulting firm, but those are some of the most common. There are also other common factors to be aware of such as support and warranty arrangements, roles and responsibilities, defect rates and agreed scope, but those are a story for another day. If you work for a consulting company this then I hope that you take an interest in exactly how your current and future engagements are structured so that you don't get caught out with some of the common pitfalls I've mentioned above.