Blog of Shaun McCran - Architecting robust, elegant technical and business solutions - Project Management

The problem with Agency life (PT1)

Fri, 01 Feb 2013 04:26:00 -0000

I've recently been discussing some of the aspects of Agency life with friends that have moved into that kind of environment and having some experience in it myself I thought I'd comment on what I consider to be some of the major differences between Agencies and more traditional working environments. I found it quite an interesting, if challenging transition when I moved from a 'normal' office environment into an Agency space. There are several key differences that result in a distinctly different atmosphere. I think it's a combination of these differences that lead to the overall difference in the atmosphere and working practices. For this first article I'm looking in more depth at the product and pricing models. Products: If you take a traditional office based working environment, the product they sell is a tangible, physical product or service. They occupy a specific market place, with a clearly defined remit and product to market and sell. This means they are an easily identified quantity. Think of the companies you know, at a brand level. Chances are you also know their associated product set. For example: Cadburys = Chocolate products
BT = Telephone products and services
GSK = Pharmaceuticals
There is a pretty clear relationship between the company and the product set / service. This leads to a situation internally where everyone is clear on the company vision, and more importantly knows what they are selling. It is clearly defined. Now take an Agency model, where the product they are selling is themselves, and the services they bring to the table. This is a lot more ambiguous than a product set, and also results in quite a heavy marketing focus on the company as a commodity. I lost count of the number of times there were guided tours around the office that were trying to establish various individuals as credible experts in their field. Think about that key difference for a second. When you go into the supermarket and pick up a product off the shelf you don't ask to see the product designer's credentials before you make that purchase, you are confident that the product is fit for purpose. In an Agency you are constantly selling yourself. Pricing: Consider the other side of the product 'Coin', the pricing model. If you have clearly defined products / services then you typically also have a clearly defined pricing model. Item 'X' costs 'Y' price, potentially with additional levels of pricing scale based on premium products. Now look at the Agency model. Typically they have common offerings based on market sector and channel. If a client wants a DM campaign or a website then there are generally 'cookie cutter' processes for the Agency to go through. Obviously they don't like advertising this to clients as every client is special and receives a bespoke service (sic!) along with bespoke pricing. The issue here is that the scope of the product varies considerably, which leads to the pricing varying considerably. This tends to be for two reasons. 1. Elements being resized during the project.
2. Some aspects of the project being prioritised over other aspects because they are deemed more important, or vice versa.
The tricky aspect to these two points is that a client has come to the Agency because they are the experts in their field. They are established best practice practitioners, and as such should be listened to. As is always the case in these things though, the people in charge of the money tend to control things. So where there is a push back on budget, the scope tends to change. Its at this point that the less tangible aspects of a project, often the most crucial aspects in my view, tend to get downsized or dropped altogether. For a client it is very obvious to see if a graphic designer has built a header banner on a page. It is a large visible element, that to them justifies financial outlay. It's tangible. Look at the less tangible disciplines of Information architecture, User Interface design or User Experience planning. You cannot 'see' any of those project elements. Yet they contribute considerably more to the success of the project than the font choice or banner imagery. This is a common conflict within Agency life. The push from the client to reduce the budget, but not the scope, and the push from the Agency to deliver on time and to budget, whilst accommodating (and compromising) on principles of the project. This was the situation I found myself in frequently. Being an expert in the field, but being driven to compromise things you know, and have communicated, would affect the successful outcome of the project. Due to financial aspects that really shouldn't be up for discussion in the first place.

Dissecting business failures: Allowing scope creep from clients

Thu, 16 Feb 2012 01:50:19 -0000

One of the most common forms of business failure that I have the misfortune to witness on a regular basis is the allowance of clients to instigate scope creep within projects. I have never understood how some industries accept scope creep as part of everyday business; let me explain what I mean. [More]

Ever had this conversation with a customer?

Wed, 09 Nov 2011 04:49:00 -0000

I saw this in my inbox this morning and just had to share it, it bears a striking resemblance to some of the conversations I've had with external and internal departments. Made me chuckle so I thought I'd share it. [More]

Three simple team-working rules

Tue, 09 Aug 2011 16:04:00 -0000

There are three relatively simple team working rules that I stick to within the office, and if you are in a team with me I expect you to adhere to them too. These aren't just rules I just get team members to use, I do them myself as well, and I believe they make a massive difference to a team's ability to work well together as a cohesive unit. [More]

Testing methodologies - Regression testing

Sat, 07 Nov 2009 17:50:00 -0000

One of the more overlooked forms of testing (you do test don't you?) is regression testing. I'm a big fan of scripted testing using both scripted tests to actually run against your code base (think cfUnit or Junit) and scripted testing as in a basic word doc of testing instructions. This word doc can be as simple as 'click button N' - what displayed on screen? You can literally just list the actions, expected consequences and actual conqequences. Regression testing is the practice of going back after a release and testing the functionality that was already present. IE did you break anything by releasing your new functionality. Often the business and IT focus is on the shiny new development, not the integrity of the existing application. Developers in particular are guilty of zoning in on the specifc area that they are directly involved with. This can sometimes lead to other areas suffering, especially if you have an OO application layer. In just how many places is each individual object referenced? A change to it may work in one area, but have devastating consequences in another. I've seen cases of this where its been months later before an error has reared its head, and without an accurate change log it can be difficult to track the root cause down. Needless error tracking and bug fixes take developers away from actually developing, and essentially cost the business money due to bad practice. I mentioned scripted testing above as it has had unforseen beneficial consequences. If you have done anything like this in the past, your regression testing will be very easy. You will have a handy library of repeatable scripted tests, so it is very easy for you to measure the previous results against any new tests you might perform. Thus making it instantly obvious wether your functionality is still behaving as it was before the release.

Post Implementation Reviews – why bother?

Wed, 15 Apr 2009 12:00:00 -0000

Often a project's success is measured by whether or not it was successfully delivered, and if the release was relatively painless. People see the finish line of a project and start making compromises or try to expedite the project delivery, as they can see that the end is in sight. It is this race for the finish that can compromise a projects completion. In my experience one of the most important parts of the project life cycle is the Post Implementation Review. It is also the most often overlooked part of the project for the reasons mentioned above, or indeed omitted altogether if a company isn't used to accurately measuring the success of a project in more in-depth terms than 'did it go live successfully' (Which is the poorest measure of success). Essentially this process answers the question "Did we manage to deliver what we set out to do". It tries to accurately gauge whether or not the business case for a project has been met, and if not, where the shortfalls are. The Post Implementation Review is an ideal opportunity to validate several aspects of the project, and feed that data back into your PM process to the benefit of future projects. It can be as basic as a simple document asking several basic questions, such as:

What of the initial business objectives did we meet?
What did we learn from this project?
What was different than expected?
Were there an unexpected issue during the project.
Would we manage any elements of the project differently if repeated?
How do our initial estimates relate to our actual delivery timescales?
How did we manage the unforeseen?

Several important sets of data should be included in it though, for example if you have any sort of estimation and/or time tracking process this is the ideal place to correlate that data with the actual project time frames as you now know exactly how long it took to deliver the project. This is an important step in refining your estimation analysis, and can greatly improve the accuracy of future projects. After all what is the point of time tracking a project, if you don't actually match up the estimated figures to the actual figures. This is also a good opportunity to examine the release management process implemented, and assess whether all potential risks to the project and the existing infrastructure were accurately foreseen. This is easily answered by a brief comparison against any release documentation you may have, as you should quickly be able to see if any risks highlighted in that were minimized. It is also a very good opportunity to explain and release shortfalls to interested shareholders. Often if a project misses a deadline, or is badly implemented it is never actually explained to the business why. They simply assume that there was a problem. By explaining here you are keeping them informed, and on-side. By explaining that here you are also documenting it for future projects. If you did not see a risk that affected your projects release this time, then surely it needs documenting and a greater level of understanding about it reached for next time. In this way you have a more complete picture of your overall architecture. Just because a project has been released it does not mean you cannot learn anything else from it, often it is entirely the opposite. Haste to proceed onto the next project can often cause this step to be skipped entirely, but once you have tried it a few times its value will become more than apparent, both as a project analysis tool, and a vehicle for shaping real process change inside the business. I will include a template at the bottom of this article that I have found useful in the past. Hopefully this brief explanation will give you the incentive to look at introducing a Post Implementation Review into your projects. An example Post Implementation Review document.