Tag Archives: style

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!

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

Notes From A Stress Fest

Kimberly Wiefling had an article today on [email protected] (www.projectsatwork.com) giving us a taste of some hard-learned lessons when dealing with project sponsors.

I’ve always loved Kimberly’s sense of humor and highly recommend just about anything she’s written. This is a great example of education a la entertainment. Check out her book too, you can buy it from the PMStudent book store by clicking on the image to the left.

In short, her exploits yield the following lessons learned with regards to project sponsors:

  1. Don’t assume who has decision power. Be clear on who the real sponsor is.
  2. Don’t assume your sponsor wanted this project. If their boss mandated them to sponsor the project, it’s going to be tough. In Kimberly’s example, ideas for projects were generated by executives, and the CEO made the decision of what to implement. The ideas for improving one division came from a different division, etc. That means the sponsors were put in charge of a project they didn’t come up with….can you say sabotage?
  3. Don’t assume your sponsor knows what their role should be. Insist on coaching the sponsor and letting them know exactly what support the project will be asking from them.

Great article Kimberly!


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

Watch Out for False Productivity

Cutting’s Edge is one of my favorite project management blogs. Thomas recently posted on the cost of project success. I enjoyed the examples of the construction of several wonders of the world as projects and their often overlooked consequences on the project teams that built them.

Thomas draws out a parallel to contemporary projects, and how in some or many cases project managers will actually plan on over-utilizing staff in their planning, or not see it as enough of a risk to take serious action.

His point is well taken, and I would like to add the pressure from the other side. I have worked with many team members who felt it is a status symbol to have been the one to work the most hours in a given week. It’s like keeping up with the Joneses. A good project manager has to be able to detect this. Signs include:

  • Spends an inordinate amount of time socializing with co-workers
  • Often points out explicitly or implicitly that they are working a lot of hours
  • Often points out explicitly or implicitly that they were the first to arrive or last to leave for the day

Many people who work 10 to 12 hour days get the same or only slightly more than those who work 8. Productivity is a ratio of how much value was added over the time it took. Aim for more productive people, not people willing to sacrifice their personal lives by achieving less productivity over more time.


project management basics

The Orchestra Conductor


Sam Hahn drew a pretty picture the other day in comparing project management and the role of the project manager to an orchestra and its conductor. I do not have much of a musical background, but even I can see the perfect parallel between a conductor and project manager. I started thinking about how the sheet music represents the project plan and is different for the various elements, and how each team member brings their own unique flair and personality.

Is there already a book written using the orchestra conductor as a metaphor for the project manager? If there isn?t, Sam Hahn should write it!

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

Catching People Doing Things Right


I had a stimulating discussion today with Travis, a friend and colleague about communication styles. It reminded me about the importance of catching people doing things right. Many managers and co-workers miss opportunities to congratulate or thank people who go above and beyond, but rarely miss an opportunity to criticize when mistakes are made.

Here are some guidelines I try to live by, and am very thankful to have been reminded of so I can re-focus:

  • Make a concerted effort to recognize when a colleague or employee went above and beyond to help you, or did an outstanding job on something
  • Evaluate the situation
    • Was it a good example of excellence?
    • Is it appropriate for you to give feedback? Would it be welcome?
    • Do you know enough about it to describe exactly why they went above and beyond?
    • Are you sincerely impressed with the example?
  • Give sincere feedback
    • Use the proper channel
      • Face to face is usually best
      • Sometimes an email to their manager may be appropriate
      • Other times just stopping by and expressing your sentiments is best
      • Public is usually best
    • Use the proper timing – immediate is usually best
  • Give credit where credit is due
    • Acknowledge the efforts of individuals where possible when discussing an effort or result. Make a point to let everyone know who did great work, by name.

Sincerity is key. If you do this every day, or for mundane things, people will see right through your lack of sincerity. Only acknowledge people for going above and beyond when they actually and obviously went above and beyond.

How about this for an exercise? When you’re chatting with people at the water cooler or at lunch, instead of talking about how frustrated you are with John Doe, talk about how Jane Doe did an outstanding job on that presentation.

Valuing Time as a Business Resource – Interview with Curt Finch

All Your Money Won't Another Minute Buy

All Your Money Won

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 below, and if you like what you see, feel free to purchase the book through the PM Bookstore.

Josh: In chapter 3, “Managing Project Risk”, you discuss time tracking as a tool for project risk management. To measure risk in terms of potential cost or schedule overruns, how can time tracking software most effectively be used for early detection of risk? How can the data be used to help formulate strategies to deal with the risks identified?

Curt: Well, the most obvious thing is that tracking time on projects (which is less common than you might

Curt Finch

Curt Finch

think in companies of all sizes) gives you an early warning system for when things are going to overrun. Projects are generally divided into phases or tasks, and if the early tasks are running longer than your initial estimates indicate they should, later phases will often run longer as well. It is very rare that people can “catch up” in the later phases; the idea of compressing later phases is usually wishful thinking. If you have a five phase project estimated at 100 hours per phase and the first phase runs to 150 hours, it’s time to go ahead and push out the schedule, add resources, or whatever else you need to do if on-time delivery is important.

Josh: In chapter 4, “Instituting a Vacation Policy”, you discuss the importance of managing PTO wisely. I agree on the points that (1) employees who leave shouldn’t be paid out accrued PTO and (2) PTO should and can be more generous when you are managing time well. What are your views on policies relating to how far in advance time off is scheduled, and the impact on projects/coverage?

Curt: You know, I don’t have a good answer for that. I’ve seen managers of critical projects demand that people take no vacation for a while until the project is hitting its stride again. In a world of knowledge workers where everyone is a volunteer because other employment options are available, this can cause your very best people to leave. Asking workers to voluntarily schedule vacation at least a month or two in advance – maybe asking that longer vacations require longer lead times – seems like a reasonable request that would enable better planning. Automated systems like those from Journyx can enable you to monitor or even enforce such behaviors.

People need time off. The company has needs too. I think that balance is required in this as in all things.

Josh: In chapter 7, “More with Less: The Build vs. Buy Decision”, you discuss this choice specifically in terms of choosing an accounting platform. A critical problem I see with many companies is one they don’t even know they have, that better time management can reveal and remedy. Setting the choice of software in this case aside, managers have to make build vs. buy decisions daily, and they err on the build side in my experience. Why? I think it’s because they don’t understand the value of their employees’ time enough to make an informed decision. People tend to underestimate the amount of work involved with new projects that are outside their core competencies. Please provide your thoughts on the application of good time management to the daily build vs. buy decisions being made by companies. A contrast between a real-world example of a company who is not managing their time well versus someone who is would be excellent.

Curt: I have seen the same behaviors you mentioned. I think they are caused by several factors:

? Employees are seen as free. Employers think, “Well, I have these guys on staff and I’m paying them anyway so I’ll just make them build it.”
? Management massively underestimates the ongoing support and maintenance cost of automated systems. Software breaks all the time, even when you haven’t changed anything. Windows ships a patch that breaks you or a slight change in usage patterns reveals a bug that was always there. And the guy who wrote your in-house system has already moved on by then. In terms of cost, many also underestimate requirements gathering, testing, documentation, and to a lesser degree, the design and creation of the software in the first place.
? Budgets for people and budgets for software or SaaS solutions are separated and unmalleable in the managerial processes of many companies. People budgets are always much higher so, again, from a budgetary perspective employees are viewed as relatively free by a first or second line manager.
? Companies may have gotten screwed by software vendors in the past. Unfortunately, some vendors raise maintenance cost too rapidly or ship what amounts to shelfware. This is common and requires forethought in the contracts initially signed with the vendor – forethought that many people don’t get around to spending time on.
? Opportunity cost is ignored because the lack of a time tracking system leads to the lack of understanding of per-person per-project profitability. There is one most profitable thing that a particular employee can be doing right now for the company. Building an in-house time tracking, CRM or issue management system is almost certainly not it. If you haven’t been measuring costs (i.e. tracking time) you can’t possibly know where you’re profitable and where you’re not.

Imagine the mythical perfect manager who has employees allocate time accurately with all expenses and fully loaded costs to every project in his portfolio. He knows which products to invest in and which customers to fire. He knows where he is profitable and where he is not. His team estimates future work accurately due to excellent historical data. His employees are aimed at the most profitable or strategic work the company has in front of it. Everyone is focused on the core competencies of the company – the activities that enhance the company’s sustainable competitive advantage. This manager is a scientist who measures things but his strategy can still be artistic.

The more common manager works with “common sense” and “gut”. In the book “Blink” we see examples of people who can really trust their guts. These people, however, live in environments where they always have a feedback loop telling them whether their decisions were right or wrong. Over time they become experts and learn to trust their intuition. Managing companies is seldom like this. You rarely know for certain if a decision was optimal in the absence of measurement, but people fool themselves into believing they know in a variety of ways. “Gut” managers seem decisive and often rise in the organization, yet many organizations ultimately fail because of them.

Josh: How important is integration of a time management system with other systems like EVMS, performance reporting, etc.?

Curt: We have seen companies that have multiple time tracking systems for vacation, projects, billing and payroll that all employees have to use. One company actually had a time code for “filling out my timesheet.” That’s demoralizing. The best system provides a global collection point and distributes data in a master-slave relationship to systems that require it. SOA is helping to move things in this direction.

Josh: How important is the time period cycle? For instance, closing out payroll on a weekly, bi-weekly, or monthly basis? What’s best?

Curt: If you’re using the data for payroll, the time period should be tied to the pay cycle. Most companies are bi-weekly or semi-monthly. I think semi-monthly works best in most cases because monthly costs are more predictable. Dispensing payroll three times in some months and two times in others leads to cash flow prediction misunderstandings, in my opinion.

Josh: Discuss some of your thoughts on time sheet adjustment policies. How should/do adjustments flow through back into other systems (integration again with other systems)?

Curt: Boy, these are great questions. I’ve thought about this one quite a bit. The answer is actually obvious when you think about it. What do accounting systems do? Accounting systems have been dealing with this problem since they were invented by the Babylonians thousands of years ago and, as you might expect, they have it nailed by now. The answer is that you close periods and don’t change them again. If you do it’s a “big deal” (as it should be), like when publicly traded corporations restate prior period earnings and their stock tanks. Similarly, adjustments to closed time periods in a time tracking system should be added as separately maintained “corrections” that, if possible, inure to the current period for reporting so that history is not changed. Those changes should flow through to all the slave systems just like new time records do.

Josh: Are there any rules of thumb you use to determine at what level it is prudent to track time on a project? Capturing too much detail is likely to cause a revolt among workers, and too little will render the whole process worthless. I’m specifically interested in any guidelines in terms of length of work packages, deliverables, etc.

Curt: If somebody has more than 20 or 30 choices on their time entry screen, they will provide inaccurate data. Our technology provides several mechanisms for making sure people see only what they need to see on the entry screen: groups, dependencies, frequent use lists, etc. If you want data accurate to the day you need to enforce entry every hour. If to the week, every day. Nobody remembers what they did last week. So if one person is going to be working on a project for 1000 hours (6 months) he should have no more than 10 to 20 phases associated with it. Often project managers want to do a lot more than that by pushing MS Project files into Journyx Timesheet, and this creates a level of detail that is unmanageable for the front line worker.

Balance is perhaps the hardest thing to achieve in life, and this extends to time tracking as well.