Blah.Blah.Blog

So the important question is what can be done to clear the misunderstanding, ensure communication is sufficient, and remove the reluctance?

One question to consider in this situation is: is it more or less cost-efficent, for the organisation as a whole, to do it this way?

Sure, the project is less effective. But perhaps making the project team more effective would be a case of local optimisation that would not be beneficial to the organisation as a whole?

Not that I'm really disagreeing - I think "BAU" sucks. But the goal of the organisation is to make the organisation work, not the project team work. The reason BAU occurs is that the powers-that-be really do think it is better for the organisation as a whole. If you want to prevent it, you need to address that issue, and arguing from a project-centric focus won't do it.

(The preview window suggests this is going to look horrible, I'm hoping it's wrong...)

My experience is as a permanent staff member, who is regularly in the situation you refer to, and also drags other people into it (i.e. I *will* steal the time of people on your project).
I've also spent a fair bit of time working on projects with consultants (and contractors) who didn't like that situation.
So let me offer the opposite perspective:

(1) I don't know who your clients are, but I'll guess that they're probably not in the software business. They're mostly going to be Finance and Telco, with the occasional Retail and Manufacturing. That means that your project is not actually their core business, it's just a tool to support the business. The core business is going on around you, and if it stops the client ceases to exist and you project goes with it. You refer to "a general reluctance to give project resourcing a sufficient degree of respect", but the opposite is also true project manager (et al) need to have a level of respect for the ongoing support of the core business.

(2) Agile values have to exist at the organisation level not just at the project level. That means that at any point in time the client should be able shift their priorities to whatever is the most important thing and if that is to solve an issue with a previous application, then that's the client's call. And they know their business and their needs well enough that they're probably making the right call. Your job is to make sure they're aware of the consequences to the project when they make those decisions, but you have to trust them to know what is going to benefit them most at this point in time.

(3) The "Commodity Programmer" myth applies to operations as well. I assume you hold to the view that "not all developers are equal" and that you want your project team to be made up of the best possible people. Hiring the cheapest available developers is a sure way to doom almost any project. (I also hold those views). The same thing applies to the support and maintenance work (the BAU you refer to). Thus, it's not necessarily a case that "Ted being the only person who understands that stuff" is due to insufficient training or planning, but also due to the fact that Ted is actually smarter/more skill/more experiences/a better problem solver/more efficient (pick your preferred adjective) in the BAU work as well as in the project work. Or to look at it a different way, if the resourcing manager had come and said, "I understand that Ted's other commitments are causing some issues - we've just hired this new graduate, would you like to swap him in instead of Ted", would you have taken it? I'm of the opinion that you probably wouldn't, but I obviously have no idea how valuable Ted was to you. Every organisation has people at different levels of experience and talent. You want to be able to put your best people on to every project, but it's clearly impossible, so you do a balancing act. You have the grads building up their skills maintaining older systems, *but* they will need help from wiser, more experienced developers.

(4) The client will still have their business to run and their staff to manage long after your project is over. The client isn't simply running a series of projects, they're managing a team and supporting a business. At the end of your project those staff are going to be folded back into the main body of the team, and will have to work with the other staff members. Sometimes the right decision for the client to make is to slow down the current project so that they can have a balanced, harmonious and supportive team for their future projects. One of the worst things that can happen to the development team as a whole is if 1 project gets picked as the "poster child" and declared off limits. All the other staff have to pick up the "BAU" to make up for the staff who are on the "most important project". When that project is over, you have a divided and bitter team that needs to regroup for the next project. The client's resourcing decisions have to be thinking beyond the current project(s).

(5) It would be nice if companies could suddenly have an over supply of well trained, experience developers who know the problem domain well and who want to work on "at-call" contracts. But the reality is that your clients are trying to balance their staff needs. They don't want to have staff sitting around doing nothing, and they don't want to force all their staff to work 50 hours weeks. They need to find the right balance of having just enough staff to get the job down at the right price. But demand isn't static. Problems don't occur at predictable times. You can't have 1 staff member who knows how to solve every problem, just sitting around waiting for things to go wrong so she can fix them. When things happen you need to be able to pull people off of projects to get stuff done - because that's where the people are. There isn't some supply of people somewhere else to draw from.

(6) Having every staff member know how to do every job and fix every system is simply impossible. I work in a team of around 30-40 developers supporting 20 applications/systems. Even if we said that every person knows how to solve every problem in 3 of those systems (which is a huge ask for the grad who has only been here 12 months, and worked on 1 project) then you have a group of 5 people to approach when something goes wrong (20/3 = 7 application groups, 35/7 = 5 people per app group). No matter how you handle that, it's going to hit someone's project.

In reference to these companies "attempting to understand/solve complex people issues by mapping them to vastly oversimplified quantitative models" - methinks you are doing the same.

Disclaimer: In the last week and a half, I have spent a total of 45 minutes on each of my 2 most critical projects because of "BAU" - One of our most critical systems had some sudden problems (80% of my time gone) and 2 of my previous projects went live and needed implementation support (the remaining 20%).
I'm very confident that my time was spent in the right place even though the managers of those projects are very frustrated about the impact that has had on their project.
So, you could say this is a sensitive topic for me right now (and you posted it on a Sunday when I actually had time to write a comment)

Hi, I really enjoy your blog, and this is off-topic, but can you *please for the love of god* make some changes to your blog template?

* larger font size (x-small is just not legible for body text)
* darker font colour (or black)
* padding between the border and the content.

Thanks for signing in, . Now you can comment. (sign out)

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

URL:
Remember me? YesNo

Comments: