project management | The Three Legged Pig

I Sing the Body Electronic – A Year with Microsoft on the Multimedia Frontier by Fred Moody

Dec 042010

This book, which covers the years from 1993 to 1995, is a depressing view of the inside of a multimedia project run by young, Generation X Microserfs who sincerely believed in the company vision. Although, with a company that large, that diverse and that disorganised, I think the vision couldn’t be seen for the re-organisations.

The book follows a group of 20 somethings from the initial ideas of the multimedia project (called Sendak until it’s official name of Explorapedia was chosen,) through to almost the delivery stage. And there are two over-riding themes that contribute to the almost failure of the project: unclear lines of control and indecisiveness.

Let’s look at these in turn.

Production Manager, Project Manager, Art Director, Lead Programmer and Chief Coffee Maker. (Okay, I make that last one up.) Throughout the multimedia project detailed in this book, the roles people undertook always seemed to be fluid in their meaning and responsibilities. One reason for this was that, as Microsoft was growing so fast, internal people were often promoted over taking in external hires and so some quite young staff ended up in fairly senior positions. People who once worked as equals, were now supervisor and supervised. Which might not be a bad thing, but without the proper training, could be quite catastrophic in the personal and professional relationships of all those involved. Here, this was experienced as the previous Art Director on another project was now the Producer (or the other way around, or the Production Manager – I should have taken notes while reading it,) and it wasn’t always clear who had what responsibility. So, one person was sometimes jumping in and doing the other’s work, and as the project went on, there would be re-organisation after re-organisation which lead to mass confusion about who exactly the decision makers were.

We trained hard, but it seemed that every time we were beginning to form up into teams, we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising; and a wonderful method it can be for creating the illusion of progress while producing confusion, and demoralisation.

– Petronius Arbiter, 210 B.C.

It just seemed to be the Microsoft Way.

The other problem with this project was the scope of what was being produced. The clearest voice of reason in all of this was the cranky programmer, who knew quite well when things had to be finalised, and not changed in order to have the code finished and tested to meet the ship date. The programmers, as the ones doing the work in the last stage of the design and development process, always appeared to be the group that had slipped and missed their milestones, rather than the designers who had missed their deadlines at the beginning of the project because of an inability to make a decision, and stick to it.

And here’s where the traditional Project Management Methodology and also Agile Project Management Methodology can fail: once a decision has been made, even though it’s software, it costs a lot to go back and re-engineer something. This project almost failed because the scope was a wibbly-wobbly kind of thing that the team never really got a hold on, wrestled to the ground and took control of. As such, late in the design and early development stages, fundamental changes were introduced that changed the game (literally.)

So, what can be learned from this? Make sure that the client (even an internal client) knows that a change in scope means changes in time and cost. It’s an immutable law of Project Management, and I know we all know it, but sometimes we need to state the obvious. Also, experience pays off – in software development most people are in their 20s, and now that I’m not, I can look back and see how inexperienced I used to be, and how much there really is to learn about process management.

The project shipped, many people were burnt out, angry, demoralised and just plain over it. But in the end, as we all know, we just get back up again and walk into the maelstrom for one more go, because we believe this time it will be better – it just has to be.

Finally, one criticism of the book: I kept getting lost with regards to who was who. Sometimes the author would use a person’s given name, and then later in the book, their family name, and then back again. So, as people changed positions, I didn’t know who the Project Manager was from the Producer to the Production Manager. It’s a small quibble, and really in the end it doesn’t distract from the book.

But overall, it’s good to see that the problems we might be having now, aren’t new. And that we can learn from history, as short as the history of software development is.

Managing client personalities

The Three Legged Pig No Responses »

Oct 312010

As a project manager, I’m always dealing with different clients at different stages of their projects. And that’s one of the things I don’t understand about Scrum: managing the competing demands of various clients. I think one expectation of Scrum is that you are only dealing with one client and one project at a time. Which makes me wonder, what do you do after your daily Scrum Meeting? Coffee and cupcake time?

So, in the world I live in, I’m always getting calls from clients or I’m calling them to get the next piece of the puzzle, or something or other. I have multiple projects running at different stages of their life-cycles. As well, each client has their own distinct personality and knowledge that they bring to the project, and so I need to deal with each client very differently to get the same outcomes.

So in order to deal with the idiosyncrasies of my clients, I have my own set of triggers that fire to warn me of the conditions of an approaching problem – my warning signs. When a client offers a suggestion for a way of doing something, the idea will flow through my triggers until it passes through to the end (a green light) or trips a few triggers (orange light) or generally causes a traffic haemorrhage (red light).

I’ll try and compare and contrast two clients I have now. Sadly, I can’t mention who they are so we’ll call one Client L, for LovelyToGetAlongWith and the other Client M for MajorPainInTheArse.

We’ll start with Client L. We’re going through the development of some online forms to collect information for their business – previously they had collected this information over the phone after receiving an initial request for information through their website. When we started there was only one form in mind, which was trying to replicate Client L’s paper based system. After doing a mock-up and discussing it with them over the phone, Client L felt that something more complicated was required. I knew this was going to happen (a few triggers had fired – no project looks the same at the end as when it starts) and I was glad that they had come to this revelation themselves. So, I dropped by their office and spent an hour going over the details and have now come back to them with a higher quote – and the one form is now split into 4 detailed forms. A good result for all of us. They have a much better solution for their business needs, and we have a more interesting project (and more money.) But the point is this, only a few of my pre-programmed triggers went off, and I didn’t have to do anything drastic because Client L had had the same experience. By spending so much time doing mock-ups now, we’re avoiding going down the costly route of premature development.

However, Client M (the bane of my life) almost always fires off most of my triggers every time I talk to him. The project itself has taken nearly a year to get where we are now – it should have been a 3 month project, and I’d say we’re at the 75% mark so far. And I’d put it down wholly and solely down to the personality of Client M. Now, for the type of business he runs, he’s perfect. But he’s not a businessman. And I think that’s where most of the problems arise. When I try and explain something to him, he’ll stop me half way and make a decision. When I try and clarify what he wants (because he’s also expect me to read his mind, and lots of my triggers are going off in rapid succession) he’ll get upset because the decision has been made and he’s explained it to me – and therefore I should understand 100%. And yet I know, some knew piece of information will come along and complicate my life.

So, let’s try and distil what I consider to be green and red light triggers in the personalities of my clients.

Red lights	Green lights
indecisive, impulsive or irrationally decisive	contemplatively decisive
shifting boundaries of responsibility	clear delineation between PM and client
decisions and progress are not made	tasks are well managed

And this is where I start getting buzz-wordy. How do Agile Project Management Methodologies handle red light clients? When a client is well educated with the process, and knows how it works, we get clients like Client L, that make my job pleasant. But with Client M, no amount of intellectual posturing will help me manage the process. And that’s where I think it’s not about managing client expectations but their personalities. If a client is impulsive, indecisive, non-communicative, ill-informed, uneducated or just a right pain in the arse, no Project Management Body of Knowledge is going to help you get through the horrors of horrible clients.

And I shouldn’t avoid the responsibility of knowing my own personality here. It’s just as important for a Project Manager to understand their own way of doing things, as it is to understand their clients. Client M isn’t as bad as I make him out to be. Really. But we’re chalk and cheese, and managing myself in the relationship is just as important as managing the client.

Agile Project Management With Scrum by Ken Schwaber

Book Reviews No Responses »

Oct 092010

Agile project management methodologies, for me, still seem to be a new thing – mainly because I was out of the game for so long. Looking back pre-2000 at what we used to do with Microsoft Project, GANTT charts and all that, Agile methodologies seem to be a natural progression in the way of doing things. Another 30 years and we’ll have something else? A new new way of managing things.

I think at the start the Agile thing was all about just trying to get away from a GANTTy way of managing projects to trying something new, or at least looking at what was working and trying to model that better in project management processes rather than trying to keep fitting the irregular shaped object into the symmetrical hole of traditional project management.

But I am in a state of digression. This Scrum book. Executive summary: it’s for cooks, not chefs. Scrum seems to be a well defined set of rules for how to do something, that have evolved through trial and error, and yet don’t seem to have a solid academic background to the reasoning behind them. Although, that could be because I’ve only read this book on Scrum, and this is a book of case studies of software development projects. And again, there’s something: it’s about software development. I’m sure Scrum could be used for other projects, something intellectual such as a business process or documentation – but that isn’t documented in this book.

Something that I do like about Scrum, is the idea of having a Sprint review and retrospective meetings at the end of each Sprint. I think these are quite often left until the end of each project, if they get done at all. Navel gazing is an important part of any process, so it’s nice to see it at stages through the project life cycle.

So, the downsides of Scrum. Those of the unbridled enthusiasm set would argue that there aren’t any – and that there is the fallacy. Everything has its downside, it’s a natural part of having an upside. So, one of the things that I don’t like is the implied inflexibility of the process. Sure, it’ll work if it’s a large project with more than 8 or so developers who don’t have other competing tasks or projects, but it doesn’t work for small business (a very small team over multiple locations, multiple projects running at the same time, etc., etc., etc.)

By enforcing the terminology of ScrumMaster, Sprint, etc. and having no flexibility with Daily Scrum meetings, it can belittle the process and reduce it to nothing more that mere spectacle. I mean really, a $1 fine for missing the Daily Scrum meeting – aren’t we adults?

Scrum also suffers from the assumption that the client will be available to make decisions quickly at the end of each Sprint. This might seem a strange assumption. If the project is that important to the client you’d think that they’d want to be involved with the project. My experience is that either the client is too involved, or not involved enough, or worse still, they vacillate between the two. Managing expectation and access is quite difficult at the best of times, it doesn’t help if the project grinds to a halt waiting for the client to approve what has been done so far and help decide what comes next.

In retrospect as well, the idea of co-located work teams can be both a blessing and a curse. If your work requires a period of concentration, then not having management interrupt you can be great. However, being co-located with your work colleagues can serve as a substitution for those interruptions. Sure, having the stimulation of co-workers around you can help you when you need it, but sometimes you don’t need it. This does come down to working out what kind of office space really works for you … maybe a mix of individual hot-pluggable offices and shared café like workspace.

So, to conclude, Scrum seems to me to be the most basic implementation of an Agile process, and that for me isn’t enough. And a book of case studies doesn’t sell me any more on the idea. We’ll take what we need from Scrum, just like any of the other processes out there, and put them into the blender and see what we get.

Older Entries