Casserole Project Management

It seems that every time a company considers using Project Management, they always start out at the same place; what methodology should we use?

Unfortunately, this is the worst place to begin your adoption of PM techniques. But I’m not going to focus on that.

Why? Because some battles you just can’t win and the idea that a methodology is so central to successful project management is so pervasive and widespread that attacking is like attacking apple pie, and I am the last person who would attack Apple Pie. Especially with a thick slice of cheese or warmed up and slavered with vanilla ice cream. Now that’s some good eating.

So, I am going to go with the idea that a methodology is important. ‘But in so agreeing, the State of New York requests that the defense stop presenting personal opinions and instead provide authoritative proof that this methodology has to be a single methodology, a one size fits all format that will adhere to every project that comes up’. And if you can tell me what movie that is adapted from I will — uh, I won’t do anything. But I will be impressed.

What is Casserole PM?

Casserole Project Management? Uh, never heard of it. But if I had, it would be this.

It is a mixture of things that at first glance you might not think about putting together.

It is chicken. And peas. And biscuits. And corn. And brussel sprouts. And who knows what else. Hopefully, asparagus. And radishes, the king of vegtables.

In the end, it is things that you don’t think of mixing together in one bowl that somehow end up going very well together when there is a little Cream of Chicken or Mushroom soup surrounding them.

And that is how project management can be. Let’s take a typical example of a typical company.

The Setup

If you are working for any company other than a software startup, this is what happens when someone gets an idea.

Of course, the idea includes IT and in fact, IT is probably at the heart of it, so the first question people ask is ‘how long will it take us to do this’ and ‘how much will it cost’. No one ever says ‘Can we do this without hurting everything else we have done?’ Heck no, it is just assumed that IT can do everything no matter how outlandish or inconvenient it may be.

And who has to answer the how long and how much question? Not some VP, but some poor BA. And what is he going to do?

Obviously, he is going to do a preliminary analysis. What is required here? What people from both the business and IT will need to be involved? What is the time frame for this development and deployment and how much will that cost?

And what do we call that type of development scenario? Yes, that’s right. Waterfall. Yes, it’s not Agile. Agile would say, doesn’t matter what the cost might turn out to be, this is something the business needs. And that is easier to determine when you are in startup mode. Once your business is established, it is much harder to say which of 25 or 200 projects your people are proposing is the most important. So you begin to ask how much and how long before you start considering what projects you can fit into your development window for the next year.

Pre-Development

Once the project is approved by the development group, then you are off and running and free to pursue that project in an Agile framework.

Or are you? Let’s face it, what the BA did above was just a very high level analysis, enough for the executive team to decide this was worth a shot. But what he came up with is very vague from a developer’s point of view.

And so, before IT management feels comfortable handing this off to the developers, we need one more step. A small one, which may take a fair amount of time and which completely nips the bud right off of Agile.

You can see the problem here, right? The essence of Agile is that the developer and the user jointly discover (by looking at test code) what is needed. But that is not what most companies are comfortable with. To be fair to big and even medium size companies, Agile only really works if you have a start up or a project that is totally different from anything the company has done. Otherwise, it is very, very hard to say that you can just open a project and let it roll in an Agile way. There are just too many priorities for a regular company. There has to be some, and maybe a lot, of triaging.

Development

Once the actual development has begun, however, then we can switch over to Agile. Or rather, we can begin using SCRUM. I am not a worshiper of SCRUM. I actually used something very similar to it in the early 80’s, but that’s not important.

What SCRUM does have, however, is a real attraction for programmers. Sometimes, when you are a coder, it seems that the end is so far off. And when the end comes, no one ever thanks you. They just wonder why it took so long.

But if you introduce SCRUM you have a one or two week window in which certain tasks will be done. And who decides what those tasks will be? The programmers. So, for once the coders are in charge of their own fate and they will work very hard to deliver whatever they have committed to. And what happens when they deliver what they say they will? The users are ecstatic. They dress up in fancy costumes and roast some large creature over and open flame, and drink an alcoholic concoction until dawn. Or at least that’s the way it feels to the developers.

So while it is not really Agile, SCRUM contributes significantly to moving things forward.

In the End

In the end, I don’t think it makes a tinker’s damn whether you approach things via Waterfall or Agile. As I think I have stated above, the two approaches are for different types of projects. Neither is the final word on how to do things.

If anything is important, it is using (a variant of) SCRUM to keep the coders moving forward. But you don’t necessarily need to do all the crap we normally associate with SCRUM. But that is another article.

In the end, the primary principles of Project Management prevail. Keep things moving. Remove roadblocks as soon as they occur. Keep everyone on the same page. Control scope creep. Keep the team with their eyes on the prize. Whether you do that in an Agile or Waterfall format is secondary.