Project Management Blog

I always thought that writing a good spec before programming is mandatory.

I like short but frequent discussions where a project spec is being written. I found out that having a spec (Agile, or not) is something mandatory. Ever since I understood I have to demand a spec from the customer, even if I have to sit down with him and write it together (frequently), programming became a much faster and easier task to commit.

It is funny that in our world of 'thinking' people, so many times we don't think and rush to program without a true moment of thinking.

If you know the road, you can reach the target.

If you start programming before having a plan, you might find yourself in a chaotic situation. You spent a lot of time programming stuff that isn't needed at all and now you have 20 waiting tasks with unknown priorities. Chaos. The customer isn't nice anymore, you are frustrated and the project becomes more and more complicated.

In cases where the possibility of getting a good spec is low there's a project management style that has to be considered - the chaotic one.

The Chaotic Project Management

1 In the beginning God created the heaven and the earth.
2 And the earth was without form, and void; and darkness was upon the face of the deep. And the Spirit of God moved upon the face of the waters.

Genesis I, 1-2

Bring the customer to your office for a couple of days or go sit with him in his. Define short tasks together and to them with his constant observation. The customer should understand that for this matter you function as his 'hands' and to the actual programming but what will be is what he asks.

Don't think about performance or beauty of code. Don't think about good DB structure, think about getting it done.

This project management style gets results very fast but it is pricey and demands great patience. It should only be used when you know you can't go a step forward in the project because of lousy communication and bad specs.

It should be done only with customers you have intimate relation with and are ready to go into this adventure with the price it demands.

Many clients don't understand what project they wish to have. This project management style is all about getting to know the project. It's about managing something that has yet been formed ("without form and void").

After a while, you'll have a clearer picture of what the project is and so would your customer.

Now will be a good time for both of you to write a good spec and manage this project in a more conservative way.

http://www.bartleby.com/108/01/1.html#S1

This article provided by dorkalev.com.

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.

This being my first entry to the project management blog I want to introduce myself. I have 10 years of professional software development and programming experience but I am relatively new to actually perform project management - closing in on two years. In my blog entries I will try to share some of the experiences I have had during my first steps in this job and what I learned from them. I will also share some tools, processes, best practices, and so on - at least these things have worked for me so they might work for you, too. Do not take my words to be the one and only truth because each project manager has his own management style but there are tips, tricks and tools that might facilitate the project manager job for many.

There is an old saying in software development about how the only bug free line of code is the one you don't write. While this may sound pessimistic, the motivation is to curb a developer's urge to over engineer a solution. When it comes to Project Management, do we have a corollary to this wisdom?

I believe we do, and it is this: The unnecessary meeting that is cancelled retains productivity. (Or at least, it has the potential whereas the meeting would have certainly doomed the group to wasting an hour)

Meetings are a necessary evil. This is so because good software requires communication between developers and stake holders, but meetings should ultimately be seen as overhead. If five people are in a meeting for an hour, this represents five person-hours not spent on features or fixing bugs. Scott Berkun, in The Art of Project Management, goes a bit further and warns against recurring meetings, which often outlive their usefulness.

There are several ways for a Project Manager to keep developers out of meetings:

• Sit down with developers and stake holders separately and confirm if all expectations are met. A five minute discussion with both parties separately may save everyone from a longer project review session.
• Start eliminating recurring meetings, or convert them to opt-in meetings, decided by the Project Manager
• Structure the order of events in a meeting so that some persons may leave early. Don't make developers suffer through a budget discussion if all they need to do their job is clarification on the software requirements.

Before you get too slash-happy, do keep in mind that effective meetings can add value. A Project Manager should enable developers to produce software. If the meeting doesn't serve this goal, adopt some meeting elimination tips from this article.

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.