Project Management Blog

While on the train heading to Paul Graham's Startup School, I brought along quite a bit of reading material. I was hoping to sleep, but I was also hoping to catch up on some reading while I couldn't be distracted with various tasking, email, etc, etc.

For example, the first thing I read was an article on "Software Development Cost Estimating" and I dug into it with interest. I happen to have a very particular way that I do my estimating - which seems to be quite accurate by the way - but I'm always looking out for more and better methods. This wasn't one of them... let me analyze this one step by step.

In the September/October issue of IEEE Software, I came across an article titled "Why Context Matters" which gets to the difference between functional and non-functional requirements and how the two interact and are interdependent.

Functional requirements are normally taken to be those hard and fast rules like "the speedometer must accurately report speed to the user." Everyone in the industrialized world has a pretty solid idea of what it should do or how it should work. Therefore, there isn't much room to wiggle.

Non-functional requirements are much more "squishy" and open to interpretation of the people capturing the requirements, the users, and those actually implementing the functionality. A rule like "the speedometer must report speed in an easily discernible manner". Wow, now we have lots of room to wiggle, which way do we go?

This is where the Context comes into play.

Over the weekend, I was discussing a couple projects with the highly esteemed Nola who happens to work with me over at CaseySoftware and a regular contributor to CodeSnipers. She was putting together an estimate for a company on a complete site redesign and functionality upgrade and was having problems putting together a solid estimate. In the meantime, I was in the thick of putting together a pair of RFP responses, so I thought I'd share my tactic for getting solid estimates:

Break everything down to the smallest steps/pieces you can.

This weekend, I picked up my issue of the IEEE Spectrum which they've devoted to software failures and started reading the fascinating article: Who Killed the Virtual Case File? It details the FBI's failed Virtual Case File System from its start to its mind-numbing $170M collapse into a steaming pile of unusable code, 800 pages of recommendations, and quite a few destroyed careers. It's absolutely stunning with respect to poor project management, so I'm going to focus on this article for a couple days to lay out where some of their biggest mistakes were and potential ways the risks could have been mitigated.

About halfway through the article, this quote floored me:
Mueller blamed himself for the delay, because he'd asked for an accelerated schedule. But Higgins blamed Mueller's staff for not being straight with him about his agency's ability to deliver what he wanted.

"Did somebody come to you and say, okay, Mr. Director, sir, you can have it sooner, but it's going to cost you this much more money or you're going to have to do without something?" Higgins remembered asking Mueller. "And he said, 'No, nobody ever told me that.' And I said, 'Well, lesson No. 1: faster, cheaper, better. Pick two, but you can't have all three.'

Wow.

In order to build this site into an open clearing house on Project Management related information, I'm putting out an open call:

If you know of *any* great sources on Project Management - books, websites, people, newsletters, magazines, etc - please let me know. I have just activated the Technorati and Del.icio.us aggregators which will be available to all. Information on companies, vendors, tools, books, etc is welcome, but all references should be *relevant* to topics associated with Project Management and should not be sales pitches.

This is a community site, let's get going.

Yesterday, I offered some points about What Project Management is Not and I promised to tell you what Project Management Is... and away we go:

Project Management is a seatbelt.

Just like a seatbelt, a good set of Project Management practices and a good plan won't do much if you're caught in a catastrophic situation. For the minor fender-benders and even bigger problems, it will definitely assist, and potentially provide some safety measures and even an escape route or two.

Project Management is a sign of something more.

Going back to the seatbelt analogy, if you put on your seatbelt as soon as you get in the car, I *believe* (no quantitative data to back this up) that you are more likely to be a safer driver. If you habitually perform good project management practices, you will be more likely to detect problems early and have a response plan in place.

Project Management is required.

For any project that involves more than a few hours of effort, some sort of planning is needed. The planning required is directly proportional to the size of the project. If the project consists of writing a new report this afternoon, the "planning" might be 5-10 minutes to think about it. If the project is version of your system, the planning will involve more people and more time. If the project is a $170M system for a major government agency, the planning will involve representatives from numerous meeting repeatedly throughout the lifecycle of the project.

Project Management is about sharing information.

Personally, I don't care if you use a text file sitting out on a shared drive somewhere. There are better tools available, but the point of all of them boils down to making information available to the required people at the required time. It doesn't matter how great your tools are if the decision makers can't get at the information they need.

Project Management is purposeful.

At some point in every project, a decision will have to be made that others are not going to like. In order to have credibility for cutting features, requesting more resources (time, money, people, etc), or pushing back against requirements, the information needs to be available to state unequivicolly "If we do/don't do X, the project is going to suffer in area Y."

Project Management is ongoing.

von Moltke's dictum says that "No battle plan survives first contact with the enemy." Having a project plan a the beginning of the project is a first step, but it's not the last. Regular evaluation, adjustment, and sometimes even retreat is necessary.

I know that last point is a repeat from yesterday, but it bears repeating. Just because you have a pretty Gantt, PERT, or Critical Path diagram on the wall means precisely nothing. As soon as the project begins, there should an evaluation of your Estimates vs your Actuals. Maybe your estimation technique was off, maybe a supporting vendor moved faster/slower than you expected, or maybe a new product is replacing some of the planned work.

If you're not regularly reevaluating the plan, you're not managing... you're coasting.

Project Management is Not a Silver Bullet.

Project Management will not ensure success. It will not make you finish the project early, to spec, under cost, and appease all your customers. Sure, all these things can happen, but Project Management tools, practices, etc, etc only allow these possibilities, they do not guarantee them.

Project Management is Not an afterthought.

If your project is out of control in terms of scope, time, money, or all three, it may already be too late. If you where flying off the road into the nearest tree, would you say "Hmmm... I think I need a steering wheel." Why is the control of your project treated the same way?

Project Management is Not optional.

I use dotProject for everything ranging from my major clients to simple upgrade tasks on CaseySoftware, CodeSnipers, and here. Excessive? Maybe. Does anything get left out? Not a chance.

Project Management is Not about tools or pretty drawings.

As a core contributor to dotProject, I have a personal and even financial interest in everyone using it, loving it, and naming their kids Gantt and Critical Path. But I don't care what you use, but use something. An Excel spreadsheet would be a step up for many people.

Project Management is Not a random process.

Project Management is about planning. It's about knowing the status of tasks. It's about taking measured risks and having plans to mitigate those. It's about looking at the cold hard facts of the project and sometimes having to say "We're not going to make it."

Project Management is Not a one-time action.

von Moltke's dictum says that "No battle plan survives first contact with the enemy." Having a project plan a the beginning of the project is a first step, but it's not the last. Regular evaluation, adjustment, and sometimes even retreat is necessary.

I know, this sounded harsh, but I'm trying to make a point. I have worked with and for many companies who say "This time it will be different! We have a Project Plan!" like it means something. Well, let me tell you something: It doesn't.

Tomorrow I'll get into talking about what Project Management actually is and why you need it.

The motto of this site is "Connecting Developers, Building Worlds". I came up with that while I was sitting in a hotel room far from home trying to get my main blog off the ground. I originally wrote it thinking of what my goals are with dotProject. I believe that one of the fundamental reasons why so many software development projects fail is poor communication... between developers, with customers, with projects managers, with testers, etc, etc, etc. I believe that this still holds, but there is another aspect that I had not considered.

Over the past two months, I have given presentations on dotProject to NoVaLUG (Northern Virginia Linux Users' Group) and DCLUG (Washington, DC Linux Users' Group) and will be giving a presentation to NoVaJUG (Northern Virginia Java Users' Group) this evening (details here). These have been a great opporuntity to connect with the community, discuss issues with other software people, and meet quite a few great people. And it made me realize that there is something missing.

I am looking for up to ten project managers who want to write, discuss, and generally contribute to a group blog. I am looking for people of all backgrounds, experience levels, skill sets, and nationality, but there are two things required. First, the postings must be in English. A conversational style is encouraged, but basic grammatical rules should be followed. Second, you should post something - a book review (linked to your Amazon account if you wish), project management issue, a howto, etc - at least once a week. I have found that most of my entries take 10-45 minutes.

What do you get for this effort? Well, nothing financially as CaseySoftware has no intention of paying you because we're not likely to make a dime from this. We plan to provide all technical support, but more importantly, I see this as your opportunity to polish your writing and communication skills, to demonstrate that you are a professional, and - most importantly - to establish yourself, your expertise, and get your name out there.

Obviously there is nothing preventing you from starting your own blog somewhere with minimal effort. Unfortunately, you'd then be a lone voice and be responsible for all the content. This way, you can benefit from having numerous contributors and the increased traffic that results. After all, if a person blogs and no one reads it, did they really blog?

My goal is to launch on 12 September.

If you are interested in becoming a contributor, please drop me a message at webmaster [at] CaseySoftware.com with an example or three of your writing. These can be blog entries, recent articles, book reviews, etc. I need to see that a) you are a competent writer and can contribute to the community and b) you are serious about this opportunity.