• A rundown of all the cool features in a product or tool
• A demonstration of a subset of a product or tool's features, usually presented as a contrived example with no real world equivalent

No one seems to be complaining about this either, which could be a good indication that the "tool-first" approach to technical presentations is exactly what the public what they want.

I would argue, however, that it is not what they need.

We get enough of the sales spin and demo-ware from the companies that make these tools. There are plenty of resources out there on the Internet for us to learn about the specific features offered by a product, with companies often employing an army of evangelists to create articles, videos and sample applications for you to digest in your own time. I mean, why give up time that you could be spending with your family/loved ones/pet projects/gaming consoles/guitar collection to hear someone read out a feature list from a product's website or run you through what amounts to a TechNet article that you could have read yourself in a fraction of the time? I just don't see the logic in it.

When I attend a presentation I want to take full advantage of having a real live human being in front of me. I want debate. I want opinion. I want war stories. I want to interact and have a conversation with the person presenting to make the experience worth my time. Ideally I'd want to walk out of the presentation with an altered outlook on how I approach work, having just had my methods questioned, changed or reaffirmed.

You simply can't get this from a straight "happy-days scenario" tool presentation where everything just works. There needs to be an underlying message and purpose of some sort; a purpose other than, for example, evangelising version 10.3 of IBM Pokemon WebSphere Black Sapphire Ruby Edition. Marketing material simply does not do this. Presenters shouldn't be afraid to do things like:

• Show the failings of a product as well as the happy scenario where everything works
• Offer an informed opinion based on experience rather than marketing material
• Discuss theory and process, either in relation to a product or tool or not
• Present on a topic that is not tied specifically to a product
• Use their technical example as a means to proving or stressing a point they wish to make, e.g. SharePoint + InfoPath + Reporting Services demonstration could be used to discuss how composite applications can provide a viable means to expand the scope of existing line of business applications to a new set of users without increasing training costs

If we don't get away from this tool-first approach then the audience are going to leave presentations believing that downloading/purchasing a product or tool will solve all of their woes, which as we all know is never the case. We get enough of this junk from software vendors; we don't need to be perpetuating this myth for them.

Around 10 years ago, when the IT industry needed to pinch another fancy title for itself after engineers got sick of us using their professional title, the term "architect" started popping up in job ads and an entirely new career path for developers was born. Sure, we annoyed real architects, but who cares about that? We had something to look forward to after being promoted to Senior Developer! Skip forward to today and we now have a bunch of job titles that sound posh but have no solid definition. Some of the generic, non-product specific "architect" roles include:

• Information Architect
• Business Process Architect
• Solution Architect
• Application Architect
• Systems Architect
• Software Architect
• Enterprise Architect
• Computer Architect
• Technical Architect
• Infrastructure Architect
• Technology Architect

Then comes the product-specific architect titles:

• SharePoint Architect
• Oracle Architect
• Cisco Architect
• SAP Architect
• Citrix Architect
• Active Directory Architect
• .Net Architect
• Java Architect
• COBOL Architect
• World of WarCraft Architect

OK, so I made the last two up, but my point still stands. There's a lot of different positions out there and a lot confusion about what these roles are actually responsible for.

As someone with the title "Solution Architect" on their employment contract I have a vested interest in clearing up the confusion around this issue. In a recent presentation I even went so far as giving "rough definitions" to some of the more common types of architect that you'll find in the wild just so I could have a common vocabulary with the audience. Here's a slightly augmented version of the list I used with a few other terms thrown in:

In an ideal world I would love to see the general architecture titles standarise on something like the list above and the product-specific architect roles go away. When I saw "go away", I mean that I'd love for people to stop calling themselves things like "SharePoint Architects". Each one of the general architecture roles I mention above has a core set of skills associated with it that apply regardless of the product space being worked in. "SharePoint Architect" tells me nothing; do you build specific applications, set up infrastructure, define taxonomy? It's much more useful to define the skillset and say that someone has a specialisation in a particular product

Using the non-product specific roles would also solve the problem of having no standard set of expectations to compare different architects. A new product being released shouldn't be a trigger for a bunch of unqualified people to start calling themselves architects just because they want to hit a certain pay grade. It would also stop Application Architects who know how to build an application on a certain platform (e.g. .Net or SharePoint) from calling themselves Solution Architects or Enterprise Architects when they don't know the first thing about orchestrating a process between different systems in an organisation (i.e. Solution Architecture) or waving their hands and spouting buzz words at the CIO (i.e. Enterprise Architecture).

I honestly think that our professional vocabulary needs to be updated to include common definitions of what we think these roles involve, and there needs to be some control over the tasks that a person has to be capable of before they can call themselves an architect. This is especially true given that we are stealing the term from a rather well organised profession that does have standards and guilds and all that other funky stuff that legitimises an industry. We don't necessarily have to go so far as having guild fees and written exams, but it would be nice if people stopped calling themselves "Enterprise Architects" because they "know a lot about Lotus Notes".

I had originally intended to present a light overview of what Business Process Management is, list some of the tools then do a deep dive into how BizTalk 2010 and SharePoint work together as an example of how you can still use SharePoint's workflow as part of a larger process management solution, but a few things happened that day that ended up making me rethink the content I was going to present on the fly:

1. I had been put on the developer track as there was no architecture track, making a discussion about integration scenarios and design patterns a hard one to have
2. Most of the presentations that day had been presented from a "tools first" point of view, which I generally find unhealthy
3. I had a LOT of business users and non-coding SharePoint folk in the audience, meaning my intention to deep dive into the BizTalk SharePoint Adapter was off the cards

I was pretty happy with the resulting presentation, and judging by the feedback so were the vast majority of the audience (There were a few haters in there that basically wanted me to do a tool rundown like most other presentations, but that's a topic for another day...), so I thought it would be a good idea to collate some of the thoughts in the following series of blog posts (links will be added as I complete each post):

• Which Type of Architect Are You?
• Issues With The Tool-First Approach to Technical Presentations
• The Fallacy of End to End Process Execution
• The BPMS Jigsaw Puzzle as it Relates to SharePoint

Hopefully I'll finish these posts soon. If not, I'll leave this post up as a testament to my slothful ways.

To that end, here's a list of the key things that each contract incentivizes the different parties to do. If you want a more in depth explanation of each contract type then check out the aforementioned post. It should be noted that these are not things that you're guaranteed to get; it's just that typically these contracts encourage people to act in a certain way in an attempt to "win the contract". It's by no means complete, but it should be a good start.

Part of the ethos of my latest blog revamp is that I don't want to be editing configuration files, modifying templates or adding anything that can't be configured using the standard WordPress admin tools. For the last few years I've been unable to easily upgrade my template to make use of new WordPress features simply because I had implemented a lot of functionality by hacking at the various files within the template. This meant that although there are a number of JavaScript-only based solutions, I would need something that is packaged as a WordPress plugin to save me having to modify my template files.

A quick scan of the WordPress plugin gallery revealed SyntaxHighlighter MT to be a reasonable sounding option. It's based on Alex Gorbatchev's excellent SyntaxHighlighter, one of the afformentioned JavaScript-based solutions for formatting source code, and was based on the use of <pre> tags meaning I wouldn't have to worry about inserting HTML special entities all over my code whenever I needed to post something.

After installing and converting over several posts I started to notice two main issues that were effectively show stoppers:

1. Anything that looked like an XML tag was being made lowercase
2. Anything that looked like a start tag of an XML element that didn't have a corresponding end tag was having one automatically inserted

This may not sound like a huge deal, but the second point was especially painful when using non-XML-based languages. Take generics in C#, for instance. If I wanted to write a line of code like this:

IList<Customer> listOfActiveCustomers = customerService.GetActiveCustomers();

SyntaxHighlighter MT would spit out the following:

IList<customer> listOfActiveCustomers = customerService.GetActiveCustomers();
</customer>

Not only did it mess up the casing on the Customer type, it thought that the generic type parameter to IList was the start of an XML tag and thus needed to be closed.

Now, I'm guessing this has something to do with how WordPress in general processes text inside a <pre> tag and is probably not the fault of the plugin author, but that still didn't change the fact that I needed a solution.

The WordPress.com guide to posting source code noted that WordPress.com blogs have access to the "sourcecode" WordPress shortcode to accomplish the very same thing. Now I'm not using WordPress.com, I self-host my blog using the WordPress.org code, but they do mention at the bottom of the post also indicates that the same functionality is available through the SyntaxHighlighter Evolved plugin.

This plugin also uses Alex Gorbatchev's SyntaxHighlighter, but it uses WordPress shortcodes just like the functionality available through WordPress.com. I've now installed the new plugin and started converting old posts over to the new format with no issues whatsoever.

The recent release of LightSwitch Beta 2 has thrown the product back into the limelight, although the exposure is accompanied by mixed marketing messages around exactly who the product is targeted at. Microsoft are in the middle of a marketing campaign trying to convince the community that LightSwitch is a tool for end users to crank out forms over data applications (we even had the always friendly Andrew Coates over here in sunny Perth to put forward that very view), but as Tim Anderson points out, the product somewhat misses that mark. Tim prefers to liken LightSwitch to a modern day FoxPro or Visual Basic, but I prefer to see it in a slightly different light.

The real potential with frameworks and tools such as LightSwitch is not to enable the end user to create applications; the very fact that IT need to be involved to deploy the application puts a stop to that. Also, it doesn't replace VB or FoxPro, both of which allow the developers a large degree of freedom and potentially allow them to run up a fairly large development bill. No, the potential is to turn the $100k internal IT project into a $10k project with repeatable results and reduced risk. This will hopefully result in IT being able to help the users who currently turn to Access and Excel for their data capture needs after being turned away by IT due to lack of funds or resources.

Think of the number of projects that get created by internal IT shops that go through full architecture and design phase, most of the time by people who haven't really built an end to end application before, and in the end they just give CRUD access to some data. There are plenty of tools in the Microsoft space already that let us build cheap, CRUD-oriented apps including:

• ASP.Net Dynamic Data
• ASP.Net MVC Scaffolding
• SharePoint 2010
• Microsoft Dynamics CRM 2011

The problem is that, even with these tools and applications, someone still has to put effort into thinking about how the application is put together. How are we going to implement business rules? What patterns do we need to use? How will we persist data? Who's going to sit with the end user while they create 3 months of work the customise the look and feel of an application that's used by 3 people?

LightSwitch is different. For me it's a piece of opinionated software much in the same way as SharePoint 2010's Access Services feature. Developing an application in LightSwitch or Access Services involves very few architectural decisions, as most of the thought has been done for you. With LightSwitch you just pick a database and decide whether you want a thick client or web based application. It's almost Paint By Numbers for enterprise software development.

It also takes the question of UI design out of the picture. Users can't argue about button placement, font size and the amount of padding on a field simply because there is no direct editing of the UI in the product. LightSwitch generates the forms from a tree view representation of the data and allows you to apply a theme, but that's pretty much the extent of it. To me this is one of the biggest selling points; adding UI design to a project is a fantastic way to kill a small IT project and would be counter-intuitive if the aim was to allow IT to assist more users.

You may think that this in some way "threatens the purity of software development", but quite frankly who cares? The users asking for the applications are currently developing their own solutions using Excel, Access, SharePoint and various other technologies that allow them to get past IT red tape. Wouldn't it be better to at least be able to bring them into the fold so the data can be backed up, the application can be supported and IT know what the application is for and how critical it is to the business?

I would love for LightSwitch to succeed in spite of the current marketing message from Microsoft. Backing the "user created applications" horse on a product that requires interaction with IT for deployment is the wrong idea; their other self-service application platforms such as SharePoint, Excel and Access have succeeded because they allow the user to bypass IT altogether. Still, I hold out hope that enough people understand the real potential of LightSwitch and other tools like it. The technology may not be there yet, but the idea of having a cheap, uniform approach to developing applications in an enterprise IT shop is one that's filled with promise.

We installed a few pre-built mods for her to play with, but things have now gotten to the point where she wants to create her own. I'm still not clear on whether she wants to actually learn Java and cut code for the mod, as she may be perfectly content scribbling instructions for me in her notebook. Regardless, I thought it would be a good idea to start collating resources on how to actually go about modding MineCraft.

Before you start anything, make sure you're familiar with where MineCraft stores it's application data; things like your save files etc. On a Windows 7 machine it generally uses %AppData%/.minecraft. Be sure to back this folder up before doing anything funky with your MineCraft install, lest you end up with a bunch of corrupted save files. You can always replace the MineCraft executable, but it's a bit harder to re-create the hours of work you may have spent building your own in-game version of the USS Enterprise:

Firstly, you'll need a copy of the MineCraft Coder Pack (MCP). Essentially MCP is a Java toolkit that decompiles the MineCraft .JAR files (the packaging format used by MineCraft to wrap up all the Java class files, metadata and resource files needed by the application in a format suitable for distribution) allowing you to edit and recompile the app. It also has a bunch of helper classes, batch files and a bunch of other fun stuff to make the experience more pleasant.

Next you'll want to check out the list of MineCraft Modding Tutorials on the MineCraft forums. If you scroll down in that forum post you'll see an excellent guide to setting up Eclipse to use the MineCraft Coder Pack. My 8 year old appreciated this as she has never seen Eclipse before; her only development experience so far has been with Python using IDLE and LOGO using KTurtle.

The list also contains some basic tutorials that get you started with cutting code against the MineCraft codebase. There are more tutorials like this on the tutorials section of the MCP Wiki

There are also a number of options for playing around with MineCraft that don't involve cracking open Eclipse. Be sure to check out the following:

• MCEdit, a MineCraft Map Editor
• The MineCraft Wiki article on Skins has some great info on modifying player and NPC skins. It also has quite a few sample skins and links off to a few external skin repositories. This is really handy for getting your head around what a MineCraft skin needs to look like before creating any of your own.
• INVedit is a MineCraft inventory editor that my 8 year old is currently using to give herself all the items she needs to create a world of her own.
• The MineCraft Wiki Mod page has a list of third party mods as well as links to various Mod managers that let you install mods without cracking open the .JAR file and recompiling it yourself. As with all development endeavors, it's worth checking to make sure that the feature you're trying to add hasn't already been written by someone else, making this a good place to check before you open up Eclipse.
• The Single Player Commands Mod gives the player access to commands that add a whole lot of functionality to what you can do in-game. Here's a cool explanation of what the mod can do:

• You can download save files (maps) that other people have created or distrubute your own.

Something cool that's mentioned on the MineCraft Wiki is the possibility of server-side Lua scripting coming to MineCraft. Notch, creator of MineCraft, mentioned it in a post way back in 2009, so I'm not sure if it's still on the cards. Still, he does mention that it will be coming during the beta, and MineCraft has only recently reached beta. If they do introduce server-side scripting then I'd imagine the barrier to entry for MineCraft modding would be significantly reduced. Still, for now it's a good excuse to teach my 8 year old some Object Oriented Programming concepts which she hasn't been exposed yet. Just a pity it has to be in Java.

Unfortunately it was not to be. My kids became the primary users of the iPad, which didn't leave much time for me to take it into work.

I managed to pick up an iPad 2 on launch day, so I figured I would give my exorbitant app purchase another try. Now, not being a Mac user anymore, I've never used the Desktop version of OmniGraffle, so I honestly had no idea what to expect. I'm a fairly heavy Visio user, and have dabbled in Aris and other modelling tools, so I had a good idea of what I wanted the product to do, though.

The first thing I noticed was that there aren't actually that many diagram types to choose from, especially in the software category. In fact, I wasn't really sure how much use I'd be able to get out of the product given that I spend most of my day creating some fairly specific diagrams.

Enter Graffletopia, the community that seems to have sprung up based around creating custom stencils for OmniGraffle. These stencils contain pre-made shapes covering a wide variety of topics, all of which you can use in your own diagrams. They even have one based around BPMN 2.0. Some of the stencils are targeted at the Mac version of the product, but there are quite a few that work on the iPad too. The site is fantastic, and I'm sure I'll be mining it for useful stencils for some time to come.

The only problem I've found with the site so far is that some of the templates refuse to open in the iPad version. Still, the majority have no issue, there are a wide variety of stencils available and the site itself is free, making it an overall pleasant experience. The functionality that it has added to OmniGraffle certainly makes me feel like I'm getting my USD50 worth.

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.

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.