Consultant Thursdays: Project Management Basics

First off, Happy Thanksgiving. I’m going in for gallbladder surgery tomorrow, so the rest of you can eat more for me, but I’m just going to sit here and post about project management.

Why?

Seventy percent of all IT projects die an evil death, that’s why.

Not all of them attributed to to poor project management (some of them are because of too many Starbucks runs), but I would guess that it may be a good part of it. You might be the project manager, or asked to be (because most project managers can be used only in larger projects), or just want to know if a project is in trouble, but it’s good knowledge to have in your belt when you encounter typical project situations so at least you can see the red flags.

We are brought in as hired guns to provide one piece of the puzzle, but what’s usually missing is a holistic view, one where all team members understand the scope of development.

Not all team members want to understand, but I can’t tell you how many times I’ve worked on a project and it didn’t come out any where close to the wireframes because of a lack of understanding of what was to be built. It’s partially my fault because I didn’t followup with the developers consistently to force them to communicate, and I think it’s all our responsibility for literally force communication.

The need for project management

As altruistic as we all are, someone’s gotta be running the ship, and that’s were project managers come in. They’re the one that have the target requirements, report status, clear roadblocks, control scope and at the end of the day, know what’s going on. Many times, they are the information architect’s best friend because they work together on what should and what shouldn’t be built.

Good project managers (and hate to say it, I’ve meet exactly one excellent one, and that goes to Carl Bailey, a project manager I worked with on BidRx) can deftly control the client and the project team with efficient and effective communication. Someone has to be held accountable to make sure the project is success, and it’s not necessarily just the project manager; everyone on the team contributes to getting the product out the door, and everyone needs to be sane about expectations.

The reason most project managers get a bad rap is they don’t have an understanding of their role (are more often than not, are too busy covering their own ass). They get the keys to the car, but many times it’s their responsibility for them to actually make sure everything’s running smoothly, and that means doing a lot of tasks that are menial, like writing down information for communication purposes.

Project managers keep task lists, keep track of progress, understand the budget and estimate productivity. There should be some kind of list that documents exactly what’s going on so communication can go in all directions.

It’s art, literally.

The metrics of project management

Here they are — bet you were expecting more:

• Resources
• Time
• Money
• Scope

Most software development projects realistically focus on three, because most projects have no concept of money (or for that matter, return on investment):

• Resources
• Time
• Scope

When managing a project, you can change two at a time — if the scope increases, you either have to add more resources, or add more time — but if you change all three, that’s a sign of a project in trouble. Run, baby, run.

To determine what’s needed of all three, you can either 1) determine the scope up front and decide how much time and resources you need, or 2) determine the resources, and set the scope and time based on this, or 3) determine how much time you have, and build around that. You ways start with one of the variables (we have to deliver something in two weeks or a month), and go from there.

Information Architects have a great influence of scope and do the project manager a great service by cooperating with them on not only focusing the scope, but discussing with developers on ways to limiting implementation time by making slight changes to the scope that don’t have a significant impact on the user experience.

Project Management Methodologies

Now that you have an idea what key metrics of a project are, how are we going to organize the project?

It’s better to start with some process than to have no process at all, because if you have something to fix, you can alter it to best fit the team i.e. change the requirements gathering process to make it faster or generate more documents for clarify communication.

There over a dozen of different methodologies, most with highly paid authors pitching their own, but two come up consistently in today’s environment: waterfall and scrum. The rest are more for elaborate projects with strict development requirements; you can look those up at wikipedia.

Waterfall Process

Exactly as it sounds, waterfall moves through the phases of requirements analysis, design, implementation, testing, integration, and maintenance. It’s generally used for big, large implementations of an ERP system, software application packages and games that are burned to a CD or have an executable install.

We’re involved in a lot of these because information architects are viewed as a resource that costs money (true) but sometimes doesn’t provide a lot of value if we’re just hanging around to answer questions (not true).

The pros of waterfall:

• A significant amount of time is spent on a design even before development begins
• Scope is fairly well defined, making it easier to estimate implementation time and hence, the cost — companies working with consultants love trying to control the cost
• It’s phases are easily understandable (I mean Fisher-Price easy, really), and roles are defined

The cons of waterfall:

• By the time you’re done, what you’ve designed might be obsolete or the wrong solution because there wasn’t the opportunity to make changes
• It’s very hard to make changes during the implementation phase
• The amount of documentation to communicate an idea is enormous (i once write 1,200 pages of documentation for a project), and there’s sometimes a disconnect between the requirements gathering team and the implementation team
• Teams are forced into silos, and there has to be an encouragement of communication
• Stakeholders have to wait months, maybe even years, before knowing what they are spending their money on is going to work

I’m not a huge fan of waterfall, basically because I don’t get the feedback loop I need to design a better project, and in many cases the stakeholders have no idea what they are designing.

Scrum or Agile Process

The project management flavor of the month, Scrum is a development methodology that focuses on short iterations (two to four weeks) of development time to produce measurable software results, and a very visisble scope of where the developers are in the process. Scrum works great for web development projects because of the single code base, and the ease most code can be changed.

One of the key components of a scrum project is that while everyone’s working in the trees, someone has to be seeing the forest iterations out, and that’s where the architects and project managers (named scrummasters in scrum) come un; it’s about the spirit and direction of the application, little grasshopper.

Software development teams I’ve seen run Scrum or Agile have had a much better time getting software out the door and get a handle on the process than a waterfall approach (who wants to work to a goal several months out?), and it provides a framework to get started.

The pros of scrum:

• Short measurable results and always a product that can be shown to stakeholders, which results in this constant feedback loop (and I love feedback!)
• Great for small teams fo 10 or less, or breaking up larger teams into smaller teams
• Encourages communication of issues without retribution, but does hold the entire team accountable for the process and the results
• The framework allows for changing the project management process for purposes of streamlining development i.e. throwing out what you don’t need and doing only what you do need to keep the ball moving

The cons of scrum:

• The design process up front is very limited; sometimes information architects have only two to three weeks of analysis time before development is itching to get started
• There’s a lot of re-factoring because of changes
• Architecture? Better have a kick ass architect or it’s going to be a mess
• Costs are not tied to scope but to the time it takes to build the project, so companies are uncomfortable with trusting the development team
• Requires a more mature, senior (and sometimes expensive) development team; the idea of throwing someone under the bus has to be controlled, and there should be someone acting at the architect

I’m a big fan of scrum (obviously), because I’ve run it and seen it work very effectively. But I was working in a small development team, and it really depends on your needs.

Resources

• At the very least, if you need a workshop or an evaluation of how to change your project management processes, contact us at pat@usabilitycounts.com.
• Amanda Abelove in Los Angeles is running a non-profit club called Scrum Club. It’s free public education and hands-on training. Pretty cool stuff.
• Paul Hodgetts, a colleague of mine, runs a consulting group called Agile Logic. They do coaching because just handing over a bible of how it works sometimes isn’t enough.
• Joel Spolsky runs something called the Fog Creek MBA, where they teach you about all aspects of software development, including project management. He’s got an even better article called Evidence Based Scheduling.

Comments