As a Mom, it is important to know exactly where everyone is at any given time, how long they are going to be there, and what they are doing while they are there. Other than that, it’s pretty simple.

As a Project Manager, it is important to know exactly what task each project resource is working on at any given time, how long they will be working on that task , what they are doing and why they are doing it. Other than that, it’s pretty simple.

Project management as a whole has paralleled somewhat the changes we have witnessed in photography. Project management also has been a skill for the few, with the barrier to entry being quite high. However, the barriers are being reduced and the chance for abandoning “point and shoot” project management is here!

There is a new design to pmStudent now in place. As I type this post, I am getting people from all over the world…

In an article at Projects@Work, Tom Mochal discusses how enhancement work not directly related to a project should be added to the managed portfolio…

The student syndrome is alive and well. I see it all around me, and I am no less guilty than any other.

Why do we put everything off until the last minute? Especially the important things?

I’ve recently read The 4-Hour Workweek by Timothy Ferriss, which has helped heighten my sensitivity to this phenomenon going on all around us.

Timothy explains in the book (and I agree) how many people fill their days up with “busy work” that takes real effort and activity, but delivers little value. Part of this is postponing those things that really add value. Usually these are the difficult tasks, which is why they are put off. It’s like subconsciously sticking our heads in the sand of minutia and busy work.

I have a renewed focus on my goal to increase productivity. I have become pretty good at being organized, which has helped. This new insight from Ferriss has helped me see the benefit of elimination, which means cutting out all the busy work that doesn’t really add much value. Instead, I plan to focus on the 20% of activities that deliver 80% of the potential value I can provide.

The same goes with my project work and writing activities. When I take a look at 50 project deliverables due, I can start to see how only about 10 of them add 80% of the value. Thus, I should focus on those top 10 and leave the ones that provide less value for later. If bottom 10-value item doesn’t get done, it will likely be much less severe than a top 10-value item. (Note that there is no necessary correlation between the value added for a deliverable and the actual cost of completing it! Interesting….)

Thanks Timothy, for showing us again that almost everything applies to project management, and project management applies to almost everything.

I recently read a new book by Curt Finch, CEO of Journyx, Inc. titled “All Your Money Won’t Another Minute Buy – Valuing Time as a Business Resource.” I have always been a student of time management, so I was delighted with the opportunity to interview Curt about the book. Please enjoy the interview.

Today I was trying to think of ways to integrate some of the methods and benefits of Critical Chain project management into the traditional PM methodology most companies use. I wanted to pick out one element of CC that would potentially yield the most benefit without much, if any, additional overhead to the project manager. Perhaps this has been written of before, but I haven’t come across it. Most of the CC proponents I’ve come across have an all-or-nothing mentality, so they wouldn’t normally write about this kind of hybrid approach. Here’s what I came up with.

Parkinson’s Law

One of the deadliest risks for slipping on schedule is Parkinson’s Law, “Work expands to fill (and often exceed) the time allowed”. I don’t believe that people on the project are lying around doing nothing because they think they have so much time (like a student might). Instead, people may be doing extra analysis and working on some ideas that might yield truly useful features. Having worked as a developer in a project environment, I can say with honesty that my co-workers and I did this a lot. We were well-intentioned, and we did good work. However, I can also safely say that many of the things we worked on didn’t address a specific customer requirement. They were nice little experiments, and developers love experiments.

The difficulty in managing projects is related to finite resources, time, and budget. Effort which addresses stakeholder requirements directly yield the most value, in that they are fulfilling what you promised. Those deliverables should be addressed first and foremost. If you have time left over, then I’d say it might be OK to work on nice little experiments that may add value.

How can you ensure resources are working on the ‘meat’ before they spend time on desert? I don’t suggest micro-management. That is self-defeating, demoralizing to the staff, and time-consuming.

The Method

Instead, let’s inject a critical chain technique into how you manage this project. Estimates on tasks are usually inflated to allow for slack time in the eye of the estimator. Let’s take the CC method of removing slack and creating a buffer, and apply it to only the lower levels, either on individual tasks or series of tasks. Take the scheduled time and chop off the last 20% of it. (I wouldn’t bother with anything less than 40 hours in duration) This is now your deadline, and the time afterwards until the “official” deadline is the management buffer. Keep communication with the team open and honest, let them know what you are doing. Their goal now is to get the task done by the new due date. If they are done by then, they can spend some time doing “Google-ish” creative brainstorming and experimentation. If not, that’s when the project manager becomes more heavily involved than normal, helping to remove roadblocks and provide more resources. Of course, the PM should be doing this all along, but now is the time to redouble your efforts. It’s important to let the team know that if they go over this deadline, it’s not the end of the world. It shouldn’t even be a negative thing. It’s just an early alert system, and everyone should know ahead of time that there’s just as much chance of going over this deadline as their is hitting it on time or early. Keep the critical path in mind with your decisions, you may have to let a non-critical path task slide to address a critical one.

By managing the tasks this way, resources are compelled to knock out the things that lead to a specified deliverable first, and add the most value. It doesn’t require adjusting the official schedules, or introduce paperwork overhead. This is simply a management technique.

As a solo developer or on a team, I think it would be great to “eat our frogs first” and then either start the next task early, or have a few days to brainstorm about what we can do to add even more value. Working with a team for a short time with a blank canvas, you can pool the skills and do some great team building while generating some really creative stuff. You could also do additional testing and debugging, or start looking at the next task early and brainstorm about the best way to go about it. Or, a little of everything. Let the ones who like engineering do things to fix bugs, enhance the documentation, and make it scale better. Let the prototypers do their thing.

Summary

• Understand CC buffer management and the benefits of it (links below)
• Get your team on board by showing them the WIIFM (what’s in it for me?)
• Keep the critical path tasks in mind for decision making
• For tasks 40 hours or longer:
  • Create a CC deadline by chopping off the last 20% of time from a scheduled task
  • The last 20% is now a management buffer
  • Check status at the CC deadline
    • Not complete: Focus support efforts on the task
    • Complete: Start the next task early, or have a “Google day”!

For some background on Critical Chain and it’s benefits, here are some references for you. Specifically, you need to understand why you’re doing this well enough to get your team to believe in it too. This probably won’t work well with totalitarian rule.

The PM Podcast Episode #57
Focused Performance
The Critical Chain Yahoo Group
Critical Chain and the Design Process – MIT
CC whitepaper from Boeing
More case studies
Yet another case study

One thing that never changes is the constancy of change. That seems like a self-evident truth, doesn’t it? So why do we plan as if change will not happen?

People in general are fairly good at managing change, but of course we vary widely in those abilities among individuals. As a result, I believe most of the time when in the planning process, we assume that we will “figure it out when it happens”.

I’m not advocating that we try to cover every scenario in our planning. I am talking about setting up systems and structures which are able to scale by design and flexible enough to not create massive overhead when dealing with change during execution. Some examples:

• When planning an application, consider building it in such a way that customization and modifications are easy, and can be performed by administrators. Many companies do not do this. Instead, any little modification requires a new project for a new release. At least make a list of the most likely items users will want to customize, and make it so.
• When setting up a schedule and/or performance measurement system, you can hard-code resource and task names, or you can use a scheme whereby identifiers in the plan have histories. Resource R23 might start out as Joe Smith, but if he is promoted or leaves the project, you may replace him with Amber Jones. With a separate history for R23, you just update the attributes outside of the schedule. Your schedule requires no update.

Now, for these things to work, you must invest more time in the beginning. With the first example, it requires more planning and programming. With the second, it’s a little more planning and a way to mesh the schedule information with the resource attributes on the fly. The data still needs to be as useful and presentable.

You can probably think of objections to what I said above. Heck, I have objections in my head already. But what if….is the cost justified….

My hope here is just to get you to think about what can be done during project planning to anticipate likely changes and make them less painless when they happen.

What do you do to plan for change?

I came across this interesting video presentation today and wanted to share. It’s only about 2 minutes long, and is methodcorp.com’s identification of key milestones on the road to a successful project management career.

I especially like milestone 5, which is the silver lining side of when most fairly experienced project managers start complaining that they are being asked to come into the middle of a troubled project. Stop whining, you reached a milestone in your career!

My apologies, everyone, for going so long between posts. I’m not blog-fading though. I think finals in conjunction with all the parental duties during the holiday season really had be bogged down.

This week, I’m the guest blogger for the University of California Extension, Santa Cruz and their “The Art of Project Management” blog. I will be doing a “Best of PM Network 2007″ series, as a year in review for the publication with my commentary on each topic area. You can check “The Art of Project Management” at http://www.svprojectmanagement.net.

Some of the blogs are going to be extensions of posts I’ve made here throughout the year, and some will be new.

Happy New Year everyone! I hope to have many new blogs coming your way soon.