Big organisation optimisation for small projects

My team and I are busy rolling out a new innovation internally here at the bank, one which I’ll no doubt be in a position to talk about in a few months. Its quite a transformational thing, and one that most people are excited about.

Yesterday, though, news of our impending internal start-up began to diffuse through our IT organisation, and I got an email from one of our accessibility experts  wanting to know if we’d done the mandatory testing that is required of any new system before live.

I’d not been aware of the mandatory requirement, but I wasn’t averse to having the testing done. So I explored a bit more and discovered that we have a testing team dedicated entirely to this process. I could engage them if I supplied an appropriate charge back code.

Naturally, I’d not budgeted for any such requirement, and as the system is being acquired from a vendor and is in any case hosted, I doubt there is much we’ll be able to do if testing finds a problem.

But we will find a compromise that makes sure we address the issue, somehow.

However this situation brings something to the fore for anyone who needs to do a small project in an organisation that is optimised to do very, very big ones.

The big project model requires lots of systems and processes. There are so many moving parts, you have to have something that imposes order if you want to get anything done.

But the small project is one that can’t afford much process and still have money left over to deliver functionality. Big project models usually condemn small projects to failure.

Is there actually a reasonable answer to the problem though? Clearly, if you have a light process model for small projects, the temptation is always to push the edge of what “small” means, just because it is easier to get things done. Sooner or later, if you’re not careful, big projects will be using the small methodology.

Is that a bad thing? Possibly not, but it does mean, inevitably, that all those not-so-small projects will start to get more process heaped on them, burying the truly small projects again.

It is an endless flip-flop between not enough control and too much.

But one thing is certain: process and controls are about controlling change, about slowing down responses so that things become predictable. They are never about moving fast.

That means, as an innovator, a key skill is knowing when to bend, and when to break the rules. And having the wisdom to do it in such a way that it doesn’t raise the hackles of everyone around you.

2 Responses to“Big organisation optimisation for small projects”

  1. July 7, 2008 at 9:37 am #

    I write about accessibility and read James’s article with interest and concern. I have posted the following comments on my own blog at .
    I would like to thank James for raising the concern and providing a view from senior management.
    My article:
    I have some sympathy for James trying to run a project and being hit by some extra work late on but I completely disagree with his conclusion at the end. Process and control should be about moving a complete project ahead faster. They should be about two things:
    * Getting things right first time so there is less rework later.
    * Providing a framework for managing the project, thereby letting the project concentrate on the implementation and not having to think about how to manage and control the project.
    The most important thing to ‘get right’ is to ensure that the project adheres to the policies of the business. For example any enterprise, especially a bank, will have business policies on security, privacy and business conduct, these are policies emanating from the CEO. The IT organisation will have developed IT policies to ensure any IT implementation adheres to and supports the business policies. It makes no difference if the project is big or small, nor if it is main stream or innovative, it has to adhere to and support the policies. The only way to make sure that happens right first time is for there to be process and controls for all projects.
    You may have noticed that I did not mention accessibility policy in the last paragraph. I only did that to make a point. I do not believe that anyone would argue that security, privacy and business practice policies exist and need to be followed. I am sure that James’s project took careful note of them and ensured compliance. The problem is that not everyone knows that the bank has an accessibility policy (I happen to know which bank James works for and I know it has such a policy). The policy is a business, not an IT, policy and basically says ‘the Bank will make its services accessible to its customers and staff’. There are obviously IT processes and controls that support this business policy.
    I am not sure why James got into this situation.
    The first possibility is that he ignored all the process and controls related to projects in the Bank. In that case how can anyone be certain that there are not substantial security and privacy shortcomings in the system that is about to be delivered. Let alone concerns about performance, reliability, usability and fitness for purpose. I sincerely hope for his sake that this is not the case.
    Another possibility is he did follow the relevant process and controls but that they did not include accessibility. If that is the case the processes need to be updated to include the necessary controls to ensure accessibility is baked in to all projects.
    What is clear is that getting rid of the processes and controls is not the way to ensure that new systems comply with the policies of the business.

  2. July 7, 2008 at 9:57 am #

    I’ll respond on your blog.

Leave a Reply

Your email address will not be published. Required fields are marked *


Proudly powered by WordPress   Premium Style Theme by