People or Process?

I’ve worked in quite a few different departments in quite a few different organisations, some were good, some not so.

But I have finally worked out what the fundamental difference between the good and the bad is.

The bad places to work focus on process, and believe if the process is ‘correct’ any ‘resource’ can perform it in an acceptable way to an acceptable standard. As long as Resource1 fills out the requirements template, Resource2, 3 or 4, or 1 can complete the design docs, and any resource can code it. Once its coded another resource can test and release it, job done. All resource can now be reassigned, sacked or outsourced – youpee.

The good places to work value people and recognise that individual skills and experience are the vital ingredients to a projects success or failure. Need to understand what the user Jo needs? ask Harry, he used to work in the biz he will be able to understand and translate it. Need a good design, get Harry to collaborate with Debs, she has architected loads of systems that all worked well. Need it coding? get Jack he knows whatever language Harry and Debs agreed will be best, He can help Harry write the code. Oh and while we are at it, why not get Jo the user involved frequently to make sure it is heading the way she expects?

All people, all social, all rewarding work, for everyone involved. But more importantly the collaboration means you don’t have to follow the ridiculous outdated, completely discredited, waterfall implicit in the faceless soulless bad co approach. So even the user Jo wins with people based development as she gets early access to shape and start using the system, and she learns a bit about trade offs.

Of course one of these represents all that was bad about 1970’s waterfall, and one represents all that is good about Agile approaches. Seeing IT people still doing waterfall is nearly as sad as seeing users retyping from one screen or printout to another. What’s doubly depressing is these two go hand in hand, in the same sad companies.

The other thing is, if you are, like me, trying to charge a premium over less experienced developers, process based places are scary. As they believe process is key, your experience and track record aren’t important or valuable to them. So, you will struggle to get anything over the general rate, and if you get a good rate you can expect an early chop. (After a painful period of being pulled back by ‘the lowest common denominator’).

Why are cos still trying to do waterfall? It looks easer to project manage. Once you have those requirements, someone can make up a guess of how long it will take and it can be programmed into the department workflow. Of course the unknown unknowns will have a bigger impact than the known requirements, so savvy PMs will at least double the guess. But a doubled guess is still a guess. You can still guess using a more agile approach, but maybe it would be better to totally revolutionise the project management and just work a prioritised list to time/cost constraints. But the inexperienced theorists in charge didnt cover that at college.

What do you think is the key difference between good places and bad places to work?



6 Responses to “People or Process?”

  1. Mathias Says:

    It’s all about the people in the team. No matter how bad the process, a good team will manage to produce something – and at best, a good process will limit the damage an incompetent team can cause.
    Personally, when considering a project/team, the thing which matter to me the most are trust, and whether open and honest discussions can be had. The process appears by itself as the team learns to work together (and each project and team has different processes).

  2. Bob Phillips Says:

    I agree with the general point about processes, I just knew the corporate world was done with me when my company started to put in a project management process, believing that their blue-eyed newbies could run the process; project management, the most important role IMO. But, I also think the two go hand in hand. You need processes, but processes that provide a solid foundation, support the task and the doer, but most definitely do not become the definition of the role.

  3. Marcus from London Says:

    You’re definitely on to something, Simon. Similar to yourself, as a freelancer I’ve worked on multiple projects, on multiple projects with multiple teams. I think this fallacy goes as far to assume that resources (people) are ‘interchangeable’.

    For me, team dynamics is probably the pivotal determinant as to the success of a project. Simply being able to work with each other is not enough. Liking and (more importantly) respecting each other and the role each plays is crucial.

    Another criteria is direct business involvement. Projects where I’ve been in the IT dept’s dungeons rather than sitting in, and interacting directly with, the business have been far less productive. Compare simply leaning across and asking the Risk Manager a question to asking the business analyst, who asks the Subject Matter Expert who asks the Risk Manager and conveys the response through the same chain.

  4. Freddy Says:

    I blame the rise of the MBA droids.

  5. Freddy Says:

    More generally, I can’t really blame senior management for wanting more predictability about when their wonderful new system will be ready, but I can blame the awful “professional managers” who pretend that they can provide that predictability.
    In particular, just because it is easy to print off a pretty Gant chart does not mean that said chart is any less susceptible to GIGO.
    95%+ of it may well be OK, but as Simon says, the minority of unknown unknowns will probably take as much time as all the easy stuff put together.
    There’s a “long tail” argument in there somewhere …

  6. DickM Says:


    IMHO the best scenario is where the client just says “This is what I need Dick. Make it so and sent me a bill.” That unfortunately takes a couple of projects with the client to get to tht point (or the application needs to be in Production and they need changes made).

    Your points are spot on about how things SHOULD be done. You should meet and involve the people who are performing the task now and who will perform the task once done. If the only people you deal with are the BDM’s and the money providers then you’re screwed (and they’re screwed) because you are doomed to fail.

    To me the best process came from my Brother-in-law “Talk a little, code a little, tes a little and then repeat over and over.” But that doesn’t go over with the project nazis in today’s mega-multi-corp.

    About your premium for being a “top-gun”, I recently did a project for a big corp where they agreed to a premium for the first month of my time having convinced the powers-that-be that I was worth it, but now the bean-counters are trying to drive me down on an hourly basis because I am corrupting their average paid to Contractors (of which I am not one BTW – I am a Consultant :-) )…. We are goig to goto fixed price I guess.

    I have also had several situations lately where the client comes to me, TELLS me what they want done, TELLS me how long it will take and TELLS me how much I will get paid BEFORE I have even seen a spec for the project…. I immediately tell them to piss off and that if they want me they will pay me at my rate up to how much they want to spend and that if I’m not done they can decide whether to pay me more or to can the project right then and there. Then I do what I think they need and what can really be done in that window of time and money. If they don’t accept those terms then I don’t want the business. Where this is a problem though is with a client who already uses your stuff and who frankly needs you going forward. You have to convince them that this is REALLY best for them and then you have to prove that’s true. Get ‘er done!.

    This is the only way I work these days and it has worked out well for me becuase I AM good at what I do both as a project manager and as a technologist in the technology I know how to use. It’s a scary way to operate but the alternative is not just scary but doomed to failure for both you and the client. In the end I always give them what they need and the price is usually justifiable. So far :-).


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: