I want to highlight a few of the things Vertabase has been doing for Haiti. This is not to toot our own horn but to point out a few extremely meaningful programs and ways to help.

1. We participated in sponsoring medical supplies that went with doctors from Holy Cross Hospital in Ft. Lauderdale, Florida. The surgeon that helped raise the money has an incredible, first-hand account of his time there. You can also contribute on the site.

2. The One Laptop Per Child program has started planning for the educational needs of the children of Haiti by launching this great collection of XO laptops for Haiti that were given out as part of the Give a Laptop Get a Laptop program over the last few years. As eary participants in this program we are sending them our XO’s.

One other neat program that is the geeks for Haiti t-shirt. You can promote your support and help your choice of charities like UNICEF and Doctors Without Borders at the same time.

A client came to us asking why he never got what he wanted from his project team.

Here’s The Replay of every project he requested.

1. Before a project began he would carefully explain the deliverable to the project manager. He would go into great details on all the intricacies that he’d worked out from months of thinking about the project.
2. The project manager would take notes and send him a specification detailing the whole project.
3. The client would think about the project some more then give the pm the green light to go ahead.
4. The project manager would set-up a schedule and deliver on time.
5. The client would take one look at the final product and inevitably be disappointed. Then frustrated. Then downright angry.
6. “That’s not what I wanted!” he would exclaim. Every time. Months of thinking about the new deliverable wasted. All his plans for using it, gone.

Needless to say, he was frustrated.

The Investigation

I went in and investigated. The process sounded alright. No glaring holes in a typical waterfall approach.

The client had a well-defined goal. The project manager was listening and delivered on time. So that’s not where the break down was.

I could recommend that the client check in every once in a while to see the actual deliverables themselves while they’re being produced. But I know he’s not that kind of manager. Besides, it wasn’t the details that were off in the final product. It was the whole thing.

I started asking the client different, seemingly obvious questions. Then, I found my answer.

“Did you read the specification the project manager sent?”

“No,” was the answer. And that was the answer.

He said it was a big, detailed document that looked thorough enough.

Gauging by the weight of the spec he was sure the project manager had the right idea.

“Besides,” he continued, “I explained it well enough for anyone to understand what I was talking about.”

In his mind, the idea was so clear and well formed that with a careful explanation it should’ve be obvious. The problem was that it was only clear in his head. He’d been the one living with it for months. He’d been the one who saw every detail. But someone it didn’t translate. A critical component of the communication in the requirements gathering phase was missing.

Communication is more than getting out everything you want to say about something (which is what he did). Communication is about making sure the other person understands.

The Core of the Problem

To come up with a solution we needed to get to the core of the problem. Knowing the people involved, the solution wasn’t simply to tell him to read the spec. It would never happen. He needed a solution where he could get what he wanted but without having him

a) do something he’ll never do or

b) change the way projects are done (e.g. adopting agile or requiring more interaction with the project team).

The core of the issue was that the specification was the wrong tool for the project manager and the client to use for their communications.

In general, a specification is the right tool for the project manager to use with his team. The project team needs a detailed blue-print. It also helps the project manager m think through the specific requirements of the project.

But it is the wrong tool to use with the client, particularly this one.

The Answer

I recommended that the project manager give the client a bullet point list of the general features. Keep it to one page whenever possible. This could even be a milestone view of the project schedule with all the sub-tasks rolled up.

If it’s too general, the client will ask questions. And it’s exactly the questions that you want to encourage. Sparking communication is one of the main goals of this approach.

A bullet-point spec is easily digested and easily scanned. It keeps the client engaged. It makes the project manager look like an efficient problem solver and good communicator. Whereas a big specification document can create the impression in the client’s mind that the project manager needs 30 pages to say what the client can envision clearly in a single image or a short conversation.

They tried it. It worked.

It didn’t happen overnight. But, it did work.

Moving to a bullet-point specification set-up a process of iterative conversations that resulted in the client and project manager connecting better and connecting more often.

This resulted in the client getting more of what he wanted, every time.

The requirements phase became a valuable, two-way conversation, rather than a hand-off of responsibility which left the client hoping he’d get what he wanted.

Milestones and sub-tasks are a powerful tool-set to improve communication on projects.  When used together in a project schedule you can consolidate the informational needs of the client, project manager and team without having to use multiple project management systems or spreadsheets.  It allows the schedule to be a single point of truth, as it were, and single reference point for project communications.

Here’s why it works.

People involved in a project have different informational goals.

• The client wants to know when things will be done and how they are progressing.
• The team wants to know the specific tasks they have to do.
• The project manager wants to coordinate the work, meet deadlines, manage resources, spot problems and improve processes.

Without a reference point, each person has trouble communicating. The client demands to know what’s going on. The team explains it in terms of the specific tasks. The project manager tries to translate between the two, or complicates matters but bringing out a Gantt chart, dependencies, a critical path or other project manager specific tools. The end result is frustration (or an exhausted project manager).

Here’s How to Do It.

You can avoid all this frustration and improve communications by creating a schedule using milestones and sub-tasks.  The milestones are the major deliverables or key points for the client. They are what the client wants out of the project and places they need to be directly involved. 

For the team, think of Milestones as parent-tasks and create sub-tasks underneath them. The sub-tasks are the specific, detailed, tasks that the team needs to do to get the project done.

When speaking to the client use the rolled-up version of the schedule showing the milestones only.

When speaking with the team use the drill-down version of the schedule showing all the sub-tasks.

This schedule then becomes the single point of truth, or reference, for all communication on the project. It has all the details needed for the team and a rolled-up view for clients.  The project manager can use it manage the project and facilitate communication without double-entry of data into other systems.

When something changes on the project you can use this schedule to show how the change impacts the milestones (for the client) or the sub-tasks (for the team). 

Taking it Further

Here are a few ways to use sub-tasks to create even more specific information that can improve communication on projects.

1. If your project management software has the capability, you can sort the sub-tasks by each team member or by due date to provide specific to-do lists for each person.
2. Using the same capabilities, you can create custom lists for your clients of all upcoming milestones in the next month across all projects.
3. Depending on the number of people involved, you can use multiple levels of sub-tasks (e.g. 6.1.2) to further categorize project information for different teams or departments that may be involved.
4. The multiple level of sub-tasks can then be rolled-up, as needed, for department meetings or meetings of team leaders.

A reader in South Africa asked if a person with strong analytical thinking skills can be a good project manager?  They’ve seen this person get very involved in the project activities themselves and, as a result, drop the ball on managing the project and keeping the ball rolling.

I answered that with the right coaching this person could be a great project manager. But, it depends on what the company is looking for in a project manager.

• If they are looking for someone to keep the flow of traffic moving, communicating between people, updating lists and assets, then it won’t be a great fit.
• If, however, they are looking for someone keep the flow of traffic moving and to document how things get done and improve the way they are done, then this person could fill the role and succeed in it.

The trick is to allow the project manager to formalize the process so that each action item is its own data point. That way the project manager can map out the process and find ways that it can be done better or faster.

It can also be very satisfying for an analytically-minded person to cross things off a list rather then shuttle back and forth, keeping balls in the air, without structure.

We released a minor update to the Vertabase Timer time tracking software today.

The biggest new addition is an auto-stop option which will automatically stop tracking time on an item when your computer is inactive for a specific period of time. You can choose if you want to use auto-stop or not and how long the Vertabase Timer should wait before auto-stopping.

This should be helpful for people who step away from their desk and the Timer was still running. Currently, you can edit the time afterwards, but this should help prevent accidental time being recorded in the first place.

You can read about the Vertabase Timer or click to Try or Buy the Timer directly.

As with all our features, this is a direct result of feedback from our users. Keep it coming.

We have a client who wanted to document their current processes. This is a good thing to do.  It has many advantages and is crucial for setting a path to growth and higher customer satisfaction.  But they seemed to always get stuck in the process.

The project of writing down the process would suffer from the worst scope creep. Then the scope creep would kill the project for a while.

Every time they’d start to get things down, they’d stop to discuss some item that came up. The discussion would grow, more people were pulled in and suddenly the whole project was pushed back for another two months.

After watching this happen a few times over the course of a year, it was clear that whatever it was they discussed, was poison to the project.

Some people suggested that it was a problem of how they were discussing the item and the steps they were taking to develop conclusions. Others suggested that it was a matter of poor decision making process and that either more power was needed to be given to the people involved or the decision itself should be pushed higher up the chain to someone who had more power.

I took a look at this situation and it was clear that none of these factors was the problem. The group itself pretty efficient at discussing things and, while it was true that the people at the table didn’t have the right decision making authority, this was not a problem of decision making.  It was a problem of content.

The items they were discussing were not part of their current processes.  They were new items, new decisions that had to be made. They were totally novel concepts for the organization and were out of scope of the project and out of the decision making authority of the team involved.  The items had more to do with process improvement then in documenting the current process.

What would happen is, that as they would document their process, they would see ways to do things better. That’s great. Its one of the big advantages of writing things down. But instead of tabling the item or making a note to come back to it later, they would tackle the issue right there.

Instead of documenting what was already in place and working in their organization, they used the whole project as a springboard for process improvement or process modification.

That, is what was killing the project.  Noble intentions and good, creative thinking, but out of scope for that project and team.

After helping them stay focused on the project itself, and creating a bucket for all the good ideas that came up along the way, the client finished documenting their processes in under one month.  They were well on their way to better management and greater growth.

After answering project management questions on LinkedIn and other sites for years, I’m happy to be able to field questions directly off the Vertabase blog.

Questions I’ve answered in the past include:

• Who defines the project objectives?
• What should I do if a client doesn’t want to hear about problems?
• What are alternatives to MS Project?
• Is a task list enough to manage a project?

Use the button on the right to submit a project management question.

I look forward to answering your questions.

While reading about information science in Ambient Findability by Peter Morville I came across the concept that gossip is an important source of information and that gossiping is an important mechanism of finding information.

One aspect of gossip is that, while it may not be 100% accurate, it can provide advance knowledge on an upcoming event or help the attuned listener prepare for what’s coming in the future.

This type of information can be incredibly valuable when managing projects. The more advanced knowledge you have on the status of tasks, projects, budgets, etc. the better prepared you can be, the better you can manage the project/plan for changes and the better you can communicate to stakeholders about it.

So I was thinking, what are the informal/gossipy type cues or communication channels that one can build into a project management process that will give managers advanced knowledge?

A mid-level manager I know expressed concern that adopting project management software would give him less control of projects. He thought that if there were a plan everyone could see and update themselves, they wouldn’t need to contact him for instructions.  And thus, he would have less control.

I explained to him that, on an objective level, he would actually

1. Have more control
2. Identify people who aren’t performing more easily and
3. Could get more done.

He would have more control since he could objectively measure progress against the plan.  He could point to specific deliverables and deadlines.  Sure, their would be less politics -and fewer meetings, but he would still be able to direct people’s actions. Only this time, instead of it seeming like the random instructions of a manager, the directions would be part of a coherent plan to accomplish specific goals. In fact, politics could be further removed from the process by having upper management sign-off on the plan before it goes into execution.

Those same objective measures can help identify where people aren’t performing and make it easier to document.  If a manager continuously needs to harp on someone for them to get anything done, it might not be a good fit. Fingers could be pointed at either the manager or the team member. But if you can consistently show that someone is not meeting the stated objectives, the finger pointing becomes much less.

His team could get more done since less time would be reporting on what they were doing or waiting to find out what they should be doing.  Updates can be made and populated automatically in the software. There will be less time in meetings. More time would be available for people to get things done.

MANAGEMENT STYLE

Of course, their may be other factors at play within the organization that make this manager reluctant to put a plan on paper or in a collaborative tool. This is totally legitimate.  A huge percentage of managers still rely on a direct and personal authoritarian approach. It can be very effective.

The vision for a good implementation of project management software is a well-oiled machine. People doing their work and following a plan, following a process that sets-up a constructive feedback loop between management and team members.  While there will always be hiccups, project management practices and project management software can help overcome them quickly and efficiently.

Regardless of management style, collaborative project management software like Vertabase gives a level of visibility, control and accountability without the administrative overhead of having meetings to find out who is doing what.

An interview with me from CFUnited 2009 was released today from CF Conversations.

It spans a wide array of topics including:

• Making project management work in an organization
• Open Source software
• Managing a software business
• Railo, OpenBD and Adobe ColdFusion

It starts out with a brief intro from Brian Meloche on things that he’s been working on then soon after moves into the interview.