Question

I’m working on a typical internal web/database app for a large corporation. By typical, I mean, a project that was projected to be 4 months and $300,000 looks like its going to be 9 months and $1,000,000.

IMHO, one reason for gross over-run is the ratio of functional people to developers, 3.5 to 2 (PM, BA, QA, and a scrum master that comes to every meeting.) About 250k of 600k has been billed by developers but at least half of that is developers sitting in meetings with functional people trying build consensus with functionaly people who are not very analytically inclined.

Many hours are also spent with the BA meeting with customers and getting buy-in for an overly complicated system that focus more on the edge cases than the core functionality. Given enough time these people will redesign the wheel as a square for fear that a round wheel might role away!

One issue here is that the BA, QA, and PM aren’t geeks and the users are staff level, mostly non-technical people. For each hour of meetings and talk and consesus building, I have to spend two hours conviencing them that they are trying to build all the flaws of a paper system into a digital system and that the power of a digital system is that 90% of the controls established by the paper system aren’t necessary.

The long and short of it is that I feel like I could write a version of the system with 90% functionality in 2 months if they would just leave me alone. Granted, it might be the wrong system but given another month or two, I’m confident that I could get it right.

So I am wondering, “what is your opinion of the optimal functional hours to developer hours on a project?” Also, “Is there any published guidance on this”

Answer 1

It sounds like you don’t have a problem with ratio of staff so much as a problem of people doing other people’s jobs instead of their own. That’s a company culture thing, and comes from upper management. If you’re upper management, work with HR to determine the root cause of the problem and fix it – if you don’t like it.

If you’re not upper management, learn to work within it or find a new job. Unfortunately, I don’t have a lot of experience in that environment, so I can’t tell you the right way to play politics. But I can tell you that you’ve got a bunch of choices.

You might…

• Tell people that they need to trust you to do your job, and that they need to do their job. When they’re intruding on your space, tell them to stop. Make sure that individual responsibilities are clearly defined, and stick by those definitions.
• Talk to your boss, and see if s/he can help put people in their place.
• Try and get the other team members overloaded with work that they should be doing, so that they’re not doing the work you should be doing
• If people want to discuss stuff about which they have no clue, and you want to make the discussion productive, explain to them that the fundamentals that make the decision obvious are well documented, and identify where, preferably text books or standards documents. If they read the documents and still disagree, point out the additional documents that they obviously haven’t read, but which they need to read.
• ignore what everyone tells you, and just do it “right” – but you damn well better pick the correct value of “right”. And you lose your job, regardless.
• Ignore what everyone else says, since they obviously don’t care what you think, and just go with the flow. Let them see the error of their ways. And you may lose your job, and get all the blame when the project fails. And don’t be surprised if the people who really caused the problem get promoted.
• Pick a developer or two whose sole responsibility is the wasted meeting time. These few, trusted developers could then take back the parts of the meetings that are actually important and the rest of the team could do their work. Note that these folk are often called “managers” 🙂

good luck – I hope someone else posts a good answer…