Tag Archives: old

Practice Project Management at home

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.

A Mom is?the “boss” of the house.? They make the rules as they go along and everyone just does what they are told.? If they decide to change the process, they don’t need to clear it with anyone, they just announce that expectations have changed, then everyone complies with the new rules.

Wouldn’t it be nice if this actually worked?? But, that is not the case.? A Mom/Project Manager must earn the respect of their team whether the team is their family at home or their colleagues at work.? The first step in earning respect is giving respect.? When you respect the team, they will respect you.

Flickr Attribution:  cambodia4kidsorg

Flickr Attribution: cambodia4kidsorg

When Mom decides to change the rules, she should get input from her team (the children) before imposing her new rules.? This doesn’t mean that the children get to make the rules, but by feeling that they are a part of the process, they will embrace the upcoming changes and they will be more willing to adhere to them.? Likewise, a Project Manager should seek input from their team before making any process changes.

Exactly how should a Project Manager introduce a process change?? First, they need to examine the existing process to determine where and if a change is actually needed.? Take the time to map out the current process and share it with the team.? If the process was not previously documented, the team may not have fully understood what was required of them.? This may solve the process issue at hand.

Once the process has been documented and shared with the team, ask for feedback on where the team feels there are inefficiencies or room for improvement.? The team may be doing more or less work than is required at any point in the process.? Understanding and following the now clarified process may solve the issue at hand.

When the current process has been documented, reviewed and discussed, try it for a few weeks before examining where changes should be implemented.

If a change is required, the next step is to brainstorm with the team on areas for improvement.? This will satisfy two requirements for change: 1) The team becomes engaged and ready to accept a change ; 2) The Project Manager is not on their own to create the new process.

In extreme cases, a Change Management consultant should be brought in to facilitate the process change.

We are operating in a world where change is the new normal.? To succeed, we need to manage change in a way that people who are adverse to it, will embrace it.

Fortunately for the Mom, children are very adapable and will readily accept of change; however, the Project Manager is usually dealing with adults who are not as open to following the “new” rules.? By soliciting input from the team, everyone will feel that they had a part in creating the new process thereby motivating them to embrace it.

Point and Shoot Project Management

My day job entails helping companies implement new project management software. Of all the companies I have worked with, including a number of household names, I would estimate that less than 5% of the managers I work with have any formal project management training. Most managers have project management training by experience in the trenches. Unfortunately, most never leave the trenches and get a better view and experience of project management. It is my experience that while there are many project managers, there are few excellent ones.

About ten years ago, I decided I wanted to learn to be a real photographer. I was tired of the point and shoot experience where more luck than skill was involved in the success of the picture. However, I quickly learned that becoming a serious photographer was quite the expensive undertaking. Besides the expense of upgrading to a professional camera, I was lacking training on how to actually use the machine. Not to mention, the cost of additional equipment ranging from lenses to tripods, and bags to filters. Lastly, the cost of film and development was high. These all became a large barrier to becoming the photographer I wanted to be. Being a college student at the time, I could not really afford to learn photography at a satisfactory pace.

However, over the past few years, new technology has largely reduced the barrier to entry and photography is now a hobby for the masses. In fact, my ability to take endless pictures without film and development costs along with the new built-in tools of my newest camera provides me the ability to progress rapidly. In many ways I can also make up for my mistakes using software and other photography tricks. I am no longer in the gloomy trenches of poor photography, but find encouragement and joy in my success.

I have observed that 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, people have still been required to manage projects. Now, similar to photography, we are seeing a boom in technology that is leveling the playing field and giving opportunities for the average manager to be an excellent manager. From new software that is principle based and collaborative to online blogs, courses, books, and other excellent resources, project management is more accessible than ever.

The key to this change from mediocrity to excellence is not simply technology, however. No technology is by itself enough to make a manager excellent. Like photography, the barrier to entry is lowered, but the effort to take advantage of it still requires an investment.

Point and shoot project management just isn?t sufficient. Project managers need to learn the basic principles and best practices for project management. Many, if not most, of these principles are methodology-independent and can be learned for free or low cost through online resources, books, or even courses. The project management tools now available do not require a degree in project management or a PMP. They do, however, require a basic understanding of project management.

Most managers have grown up learning point and shoot project management. Trial and error project management is far too expensive, but it continues to be the most dominant. Organizations and individuals need to put forth the investment to learn. The lower barrier to entry should encourage us all to take project management to the masses!

Bringing Support Activity into Portfolio Management

In an article at [email protected], Tom Mochal discusses how enhancement work not directly related to a project should be added to the managed portfolio. This way, the business can ensure that the dollars are being spent in the most effective way on these non-project activities.

I agree with what Tom is saying. A point I’d like to add is that value judgment is in the eye of the beholder, and incentives are different for a portfolio manager than they are for a developer or department. The “enhancement” being worked on by a few individuals may take a lot of effort, but is the work being subjected to cost-benefit analysis beforehand? If it is not being managed with the rest of the portfolio, maybe not.

For instance, a developer may have a great idea about migrating an internal support application from one platform to another. There are many benefits of doing so, it will be faster and he can also make it look nicer while he’s at it.

But what if it works great just the way it is? What if the changes will create dissatisfaction for the users within the company? What if the business processes already have slack time for the application because the user is doing something else, and the increased speed will not result in overall improvement because it’s not the bottleneck in the first place?

These are questions a portfolio manager may want answered. A department head or manager may be more concerned about holding on to their budget than doing ROI analysis with all of these support activities. It’s all about incentives. The department head may be able to say we “doubled the application speed” and that looks great on a quarterly report.

Bringing some of these decisions into a portfolio with defined projects would certainly help ensure that the incentives of the decision-maker is more in line with the incentives of the business as a whole.

project management basics

Lessons Learned from Anita Wotiz

Anita Wotiz is the guest blogger this week over at the UCSC Extension in Silicon Valley Project Management blog. She published great post titled “An unrepeatable success?” Read it here.

It was great to hear about the project, specifically the lessons learned and trying to relate them to my own experience.

I wouldn’t write the first set of factors off as things that can’t be duplicated. Sure, it’s easier in some cases because these things fall into your lap, but these can be influenced to some extent. Paraphrased:

  1. Good team (competent, cooperative) –A PM can sometimes influence who works on their project, and ensure they are competent. Cooperation and team spirit is largely influenced by the PM, in my experience.
  2. Exciting work –Not every project is glamorous on the face of it, but the PM can and should figure out how to position the product being created to the team by selling them on how much value it will add for the end users, and how their individual and team contributions make it possible.
  3. Full access/utilization of previous work –Again, this usually doesn’t fall in your lap, but it’s amazing to me how many project managers don’t spend enough time during the planning phases trying find previous work that can be re-used. Many seem to want to re-invent the wheel with each project.

As for the other factors, paraphrased:

  1. Don’t constrain the project to a preconceived solution –Three points; I see this so many times, where the sponsor and stakeholders have a preconceived notion of what the solution should look like before they even fully understand the problem! Granted, sometimes there are real constraints that are necessary. I think it’s human nature to start coming up with possible solutions very early in the process, and difficult to avoid. Personally though, I’ve found the best results come from forcing yourself to focus strictly on the need/problem during early planning, including the charter, preliminary scope statement, and initial requirements gathering processes.
  2. Good WBS creation and decomposition, bottom-up estimating –Bingo! This agrees completely with my experience about what helps make a project successful. I’ve had a lot of luck in the past using a delphi-style method of estimating, where we go through each task in a room with the experts who will be performing them, and each person writes down an optimistic, likely, and pessimistic point estimate. I take all the estimate sheets afterwards and roll them together, ask about any outliers, and can usually come up with pretty good ranged estimates with a solid grasp on standard deviation and confidence levels.
  3. Management cost/time buffers available –I agree that it’s critical for the sponsor/customer to realize that buffers are there for a reason…they are not just downtime or waste, they are crucial components of a good project that can handle the inevitable risks that will arise.
  4. Collaboration –It sounds like Anita was able to get the whole team to collaborate on scheduling by using post-it notes on the wall. I think that is excellent, although alternative methods may work just as well to have the team collaborate on schedule and task dependencies.
  5. Iterative Development –This is a benefit I’ve used and seen in my projects too. If you can push out iterative releases that are functional, you can start getting feedback from the customer and make subsequent development based off a real foundation, instead of a theoretical one. Writing code to specs is one thing, but if you can immediately test it against an initial release of the pieces it has to integrate with, you’re way ahead of the game.

project management basics

Put Off Procrastination

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.

project management basics

Moving Beyond the Triple Constraints

Dave Garrett recently wrote on the concepts expressed by Aaron Shanhar in his book, Reinventing Project Management. The gist is that the common triple-constraint model of managing cost, schedule, and scope is not enough. As I like to put it and in Goldratt’s words, necessary but not sufficient.

I have not yet read Shanhar’s book, but have a few initial thoughts based on Garrett’s description.

The notion feels right. I have observed a few specific behaviors that may come about because of the framework of incentives set up by the traditional approach. First, quality assurance seems to be an afterthought or necessary evil in many projects, if it happens at all. I agree with the notion that the triple constraints are efficiency-focused. They set up incentives to meet the requirements, even if those are the bare minimum. Many times, scope is reduced as a result of cost cutting efforts, and they are looking for whatever will provide barely satisfactory results. Activities are dropped without a thorough analysis of what the impact on quality, team morale, etc. might be.

Second, I have known many project managers to define success as sticking to the requirements, even if they are very bad requirements. There’s no incentive to put a lot of effort into quality requirements if a project manager knows they will still have met scope, schedule, and budget. In other words, you can have a failed project which meets all three constraints. Interesting….doesn’t sound like success criteria.

I agree we need a better model with which to think about projects holistically. I look forward to reading Reinventing Project Management, and learning more.

project management basics

Critical Chain Benefits From Traditional PM

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.


  • 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

PM Network – Go, Team, Go!

I finally got a chance to read this month’s PM Network magazine. There is an article on keeping project team motivated that caught my attention starting on page 38, written by Simon Kent.

The article reminded me of a previous post I wrote back in February, 2007 titled Motivational Theory in Project Management where I laid out some of my thoughts on the topic, specifically in relation to Frederick Hertzberg’s work.

The PM Network article is mostly in line with Hertzberg. Instead of focusing on theory or concepts, the article mostly cites specific examples of how various project managers motivate their teams and keep them that way. I enjoyed the experiential approach to the topic.

Jonathan Bowman cited monetary rewards, and he’s right in saying that you have to be careful how that is done. Team-wide bonuses for early completion or coming in under budget are good ways of doing this. Hertzberg cites monetary compensation as a hygiene factor, not a motivator, and I am inclined to agree with him. Money can be used as a force for recognition however, if directly linked to accomplishments. Personally, I would stay away from giving individual bonuses based directly on project performance. This could provide incentives for people to excel or look good at the expense of someone else and/or the project objectives. Instead, accomplishment should be documented in the performance review process and have their relevant impacts on salary increases.

Here are some of the techniques brought out in the article that I especially agree with:

  • Create a team area for co-located projects. Do some banners and sit people who are on the project next to each other whenever possible. This fosters communication and can help create a better team atmosphere.
  • Create a learning experience. This one I really enjoyed. It speaks to leveraging strengths of your team members, while assigning them a supporting role in some other area they are interested in learning more about. This way, they can learn without creating undue risk and stress that would come from just assigning them responsibility for something they unexperienced with.
  • Use a monthly ‘team barometer’ to gauge how things are going on the project. Joli Mallick, PMP offered this up, and I think it’s a fabulous idea. It’s such a good idea, I’d like to throw out some of my thoughts on how to implement it:
    • Exactly 3 targeted questions, no more, no less.
    • Completed monthly via a website or survey tool of some kind.
    • Anonymous
    • No multiple choice. All free-text.
    • The questions are generated by the head project manager, with input from subordinate project managers and leads.
    • The questions change throughout the project. Using the same questions over and over is boring and irrelevant. A team member gets the sense their feedback is actually being used if the questions are original each month. This shouldn’t be a tracking tool to measure communication performance or something. It’s a direct feedback mechanism for actively managing projects day-to-day.
    • Use a monthly status meeting to review the results and discuss the problems and solutions.

Something like the above would take a few hours each month to administer, analyze, and communicate. It would be worth it though. This is like a Delphi method session each month to highlight the biggest problems and concerns on the project as early as possible. The time spent should not be difficult to justify.

Scope Verification

Scope verification is defined in the PMBOK as “the process of obtaining the stakeholders? formal acceptance of the completed project scope and associated deliverables.”

I’ve been thinking about this process recently, and would like to share a few thoughts on the matter. When you start thinking about the details for how this will work on a project, some questions arise.

What is scope verification anyway? Are we only making sure that specified deliverables have been completed? Often, the related but seperate activity of quality control is confused with scope verification. Quality control should be a check before scope is signed off as complete, but that process should measure quality against the quality baseline established at the onset.

Scope verification has to be written. Otherwise, it’s not really scope verification. A status meeting where you talk about the state of the project is a status meeting, not scope verification. Even if you list accomplishments, there needs to be a formal sign-off. Otherwise, what’s to stop the stakeholder from coming back in 6 months to revisit something and say they didn’t like it?

Project Monitoring

Hello everyone! I’m sorry it has been so long since my last post. I have been going through a job change, and the last month has been hectic with getting things shored up at my previous company and (trying) to get up to speed at the new company. I recently listened to my favorite podcast, The PM Podcast, and episode 75 is about project monitoring.

I really enjoyed this episode. Upkeep during project execution and finding problems as early as possible has always been an important topic for me. I think that is why I found interest early in the Critical Chain methodology, because it offers great ways to highlight and pinpoint problems early on. In particular, I felt the soft skills addressed in the discussion were very important. After all, you can have mountains of data, but if you don’t know how to present it well or what to do with it, it has no value. My key interests are being able to take quantitative data from something like EVM and combine it with qualitative data in order to target specific work packages, resources, or stakeholders who are having/causing issues.

I will let you listen to the podcast, but it was wonderful. Also check out the accompanying power point presentation here.