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

0 Comments Continue reading

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.

2 Comments Continue reading

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

4 Comments Continue reading

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?

1 Comments Continue reading

This may be the most controversial point, but in my opinion it is aligned with the rest of Deming’s philosophy nicely, and I agree with this point totally. In the US especially, Management By Objectives (MBO) is very much the status quo. I’ll give a short explanation of my opinion from an operational standpoint first before relating this concept to project management.

In MBO, standards are set for a particular process with the intention of evaluating employee performance by them. Performance in relation to the standard weighs heavily (and is sometimes the only factor) in merit increases, bonuses, etc. A standard example would be handle times in a contact center environment. If the standard handle time is set to 3 minutes, and you are taking an average of 4 minutes, it is said the employee is performing poorly. This paradigm assumes that the measured metric (handle time) is the full responsibility of the employee. Pros and cons of this management philosophy:

Pros

• Easy to set expectations
• Easy to quantify
• Easy to base performance evaluations on

Cons

• Tends to move the focus to being ‘at’ standard
• No focus on process variability
• Tends to make the standard the ‘only’ performance measure
• Provides little incentive to improve processes when the standard is being met
• When defining standards, operational leaders tend to lean towards lower standards in fear of not meeting them
• Propogates the ‘carrot and stick’ approach where fear usually wins out as the strongest motivator
• Discourages educated risk-taking and experimentation with processes, because it might throw people ‘out of standard’ temporarily
• Discourages employees from helping each other by encouraging detrimental internal competition
• Forces employees to try and acheive contradictory goals (”I want to provide great customer service and spend the time the customer requires, but if I do that the way I know it really should be done, I’ll miss my standard and get written up.”)
• Employees and managers may be motivated to skew results so their numbers look better
• Moves focus from customer satisfaction to “covering my butt.”

You can probably tell that I don’t like Management by Objectives. To me it seems like the easy way out, and very much the wrong approach. Deming would say that 90% of defects in any situation can be related to poor systems or the lack of systems in place. Most people want to do a good job and will follow a process when it is well designed and they have the ability to provide input for it’s development and improvement.

Let us discuss this point in terms of estimating project tasks for duration and cost. In the MBO paradigm, what usually happens is that a project team member is given a piece to plan and estimate. Many times there is no process for them to follow in making their estimates. The project manager assumes they are the SME and know how to estimate. The PM may not really have a good idea of how much time they will be able to devote to their project work, alongside all their other projects or daily duties. In many cases an experienced team member is going to throw on a lot of slack time because they are in fear of missing their estimated deadlines. In any case, an MBO mindset is going to lead everyone to blame individuals for mistakes. It doesn’t necessitate a focus on improvement.

What would a Deming approach change? First, there would be a process in place to help guide estimates, evaluate performance to planned estimates, and go back to figure out why estimates were wrong. Another option might be to change the resource load so that a team member can devote all or most of their time to a project for a limited period of time, thereby reducing the cycle time on their deliverables (for your and other projects) and allowing them to more easily estimate in terms of effort required. Part of the process may be to train and guide them in doing a lower level of WBS to break things down into 4-16 hour chunks. It is going to be important in a Deming approach to evaluate tasks that took longer or shorter than anticipated. Not to place blame on the individual who did the estimate, but to find ways to enhance the process of estimating to make it more accurate in the future.

0 Comments Continue reading

Deming’s third point urges practitioners to design quality into processes, using inspection as an information-gathering tool to do so. In project management, the processes and systems make up a methodology. Does your organization have a consistent methodology, or does everyone run projects their own way? Inspecting project performance through the lens of continuous improvement facilitates applying lessons learned to a consistent and ever-improving methodology. This can not be done effectively unless there is a consistent system of managing projects in the first place.

Because projects are inherently unique, the specifics of how they are managed may require modification on an individual basis. If a consistent methodology is used as the basis however, deviations can be reviewed and further enhance the methodology by documenting best practices for specific categories of projects. The “deviations” can be developed into subject-specific best practices within the common framework. Furthermore, various components of the methodology should be a guideline, whereas critical planning processes should be standardized as much as possible to facilitate the formation of sound theories and best practices. For example, the methods of estimation should be consistent, while some aspects of management style should be left up to individual project managers.

Too often, inspection on projects is used as (or believed to be) a method of blaming project managers when their projects are behind, or applauding them when the projects are ahead of schedule. They should be neither. A performance report indicating a significant discrepancy in the planned time, cost, or quality should be viewed as an opportunity to go back to the planning process and figure out why it was so inaccurate. If the project manager followed the planning processes outlined in the methodology, this is new information with which to enhance those planning processes. If the issue appears to be execution, find out if the project manager is abiding by the guidelines set forth in the methodology, or if they are ignoring them. Compliance can be a people problem, but Deming would argue that over 90% of the problems in any situation can be traced back to flaws in the system, not the people.

When appraising the performance of project managers who work within a consistent methodology, performance to plan should not be such a large factor. Instead, the (1) ongoing contributions to improving the methodology and (2) compliance and success of execution should be considered. Not using the methodology can lead to poor performance, but it is better to measure the cause, instead of the result. To me, this is a key distinction in the Management by Objectives philosophy of people management versus Deming’s view on how performance should be evaluated. Think on the incentives in the MBO versus Deming management philosophies.

In MBO, a project manager may be enticed to add so many schedules and cost padding that they are always the hero when they come in under budget and ahead of schedule. They can negotiate out many beneficial features and other quality elements of the final product, and then if they add a few back in because of all the extra time and money, they win again. This factors into why many projects only meet most of the customer needs, not all of them. In my opinion, this is what makes project sponsors slash schedules and budgets….they know what is going on. The project managers add even more fluff because they know it will be cut down, and the vicious cycle continues. Where is the incentive for continuous improvement? The focus is clearly misdirected.

If one were to apply Deming’s philosophy to project management, much of the struggle from above is avoided. The focus shifts to creating and continually improving a consistent system from which project managers plan and execute projects. The addition of arbitrary amounts of fluff time and cost by project managers is not possible if there is a specific, universal method for making estimates. Contingency reserve is still there, but in a consistent manner based on what makes sense for the organization.

Project managers are encouraged to embrace and improve the methodology. Rewards and recognition result from actions that truly enhance the entire organization’s ability to provide quality to the customer. Regular reviews of lessons learned and other input from project managers can be used to enhance the methodology, one small step at a time. Statistical measures across multiple projects such as standard deviation from plan and EVM metrics can provide useful insights into opportunities for improvement.

Performance excellence does not happen overnight, and it does not happen to an organization as the result of a few great individuals acting in silos. Performance excellence occurs over years of embracing a consistent set of systems and processes that everyone seeks to continually improve.
Project management is about dealing with uncertainty. The point is to eliminate as much of it as possible through careful planning, and deal with the inevitable unknown-unknowns appropriately. Deming’s third point when applied to project management eliminates much of the uncertainty in projects by using an invariant framework which can be continually improved.

0 Comments Continue reading

I responded to a question on the PMI member forums that I wanted to share:

Subject: Critical Chain Project Management

Does anyone have experience with this PM approach/toolset. I have run across some people proclaiming it as the savior of project management (unfortunately, the biggest proponent I met seemed to think that a Project Plan is all there is to Project Management and expressed enough negativity regarding PMI and the PMP designation that I found it hard to give credence to the validity of his information).

I am interested in any validation of its effectiveness beyond anecdotal evidence.

RE: Critical Chain Project Management
Posted by Joshua Nankivel on 01/18/2007

I personally have not had the opportunity to implement critical chain on anything except very small projects. I can give you some good resources however, citing individuals and organizations that have had success with critical chain project management.

1. The PM Podcast Episode #57. – I don’t recall specific examples Alan cited on the show, but I might be wrong. You may be able to contact Alan Elder at the email address listed on Cornelius’ site directly for some direction.
2. The Critical Chain Yahoo Group – has a lot of active contributors who utilize critical chain on a daily basis
3. This whitepaper from Boeing can be downloaded upon request, I requested and read it and it’s a really great overview of how critical chain was used in a real project. Very well written.
4. More case studies
5. Yet another case study

I would add that I have run into some people/articles that seem to be overly confident in critical chain. I think it has great potential, but it’s only a piece of the puzzle. I look forward to using it myself on larger projects in the future.

Also, one of the things I post fairly frequently about on my blog is critical chain project management. If you’re interested in critical chain even the broader scope of project management in general, I’d (of course) suggest it!

Cheers!

Josh Nankivel

Please leave comments about this post!

Continue reading