Myths and Procurement

Most companies that buy goods and services employ some kind of procurement system. The logic is simple - to ensure that the organization gets good value for its dollar. But for many organizations, something has gone off the rails. Processes that were intended to allow for dispassionate acquisition are now crushingly bureaucratic reality shows. Rules are invented to frustrate the respondents. And the system is gamed, more often than not by the very people who insist that procurement processes are vital to the company's well-being.

Earlier this year, I reviewed an RFP outline of the rules of engagement for the process. One paragraph noted that respondents who do 'X' will be disqualified from further consideration. A later paragraph said that respondents who did NOT do 'X' would also be disqualified. This discrepancy was raised by vendors during the Q and A. The issuing organization's answer? Do your best to figure out what is the correct way to respond. It's a testament to the imbalance of power in the procurement world that some organizations actually responded.

So how can you tell when your procurement system is polluted? Check for some of these behaviours:

1. Have suppliers ever been involved in writing evaluation criteria for your RFPs? Try asking a car salesman to help you determine what you need in a car. I guarantee you the criteria will revolve around their differentiator.
2. Do responding rules promote a level playing field (e.g., open Q and A sessions)? Or do they create hurdles that may help you filter, but not really evaluate, respondents (e.g., disqualifying submissions that deviate from a prescribed format)?
3. Do you cancel RFPs routinely? Of course, by wasting your vendors resources you raise the prices you pay.
4. Are procurement rules routinely circumvented? Do senior managers follow them? Do employees chop up their acquisitions to keep them under certain thresholds in order to avoid justification processes associated with larger procurements? Mix with bullet 1 and you've got the Ontario Premier's nightmare.
5. When creating an RFP, do you try to ensure that the distribution of risk is fair between the supplier and the buyer? Or do you try to get as much as you can without having any of your own skin in the game? What would you do on the receiving end of this kind of tactic?
6. Do you rely on cost-minimization strategies to select vendors? These days, this antiquated view of value propositions is routine in public institutions like hospitals and often coupled with bullet 5. Trying to minimize both cost and risk may seem like a noble strategy, but it is incredibly naïve.

Your procurement system can do much to support an 'arms-length' dispassionate approach to buying? Or it can just 'stiff-arm' potential partners that could provide real value to your business? And if that's what happening, who is it really hurting in the end?

PM Views: In Search of Better Goals

Some time back, I was working with a client to help them get better at managing projects. Of the many projects they committed resources to, very few had a clearly-defined and well-understood purpose to which team members and stakeholders could refer. They jumped all over the 'how' without really understanding the 'what.' So we set to work on building some definitions for our projects.

Of the 10 project managers I was working with, 4 of them developed charters and scope statements indicating that the main objective was 'to reduce the FTE count in Department X by Y%.' Big flapping red flag!

Me: "Who are these FTEs?"
PM: "Well, some end users and some team members."
Me: "What happens when FTEs are reduced?"
PM: "People get packaged out."
Me: "How's the project going?"
PM: "Not very well. No one's too excited about it."
Me: "Wonder why ..."

To me, there is an intimate relationship between this kind of thinking and the economic dive of the past year. Money has been treated as the only asset and people are just a commodity. It's a 'killing the golden goose' thing.

Project managers can influence this kind of thinking for the better. Let's engage our sponsors and stakeholders in a dialogue about the big picture. What might be possible for our organization if, through our project, we could free some of our talent to pursue things of higher value? Why not make THAT a goal of the project rather than simply shaving some dollars off the expense column? The PMI Code of Ethics completely supports this approach. And doing so distinguishes us as more than managers. It demonstrates leadership.

PM Views: What is 'Communications' Again?

I've done a fair bit of work of late as a subject matter expert in the area of Project Communications. Even so, I struggle to understand what it really *is.* I have an 807 page book on my shelf about Project Communications that goes on and on about how to manage it, but never defines it!

I feel about communications the same way I feel about the colour orange. Some days it seems like it's a colour all its own, but often enough it just seems to be a variation of red or a saturated yellow. And maybe that's it. Perhaps communication isn't so much a thing unto itself as it is a vehicle for, or enhancement of, something else.

When I'm really communicating with someone, I feel a sort of *click.* I can often see it in the other person as well. Something happens that is bigger than either of us. It is the most energizing part of managing projects for me - getting to the point of *getting it* so that my team and my stakeholders can share in project success.

Effective communications in projects is like model airplane glue. Applied well, you don't really notice it in the end product. Used sloppily, you end up with gobs of glue all over the place. Sure, the airplane is held together, but it's best to stand back a few feet so you don't notice the disaster of the execution. And if I spend too much time around communications *templates* I start to hallucinate anyway.

PM Stories: High-Risk Advocating

I was managing a project to produce a web-based application for use during a scheduled training event at a client’s site. On one side was my sponsor that was extremely eager to launch. On the other side were developers trying to create code for complex business rules. As my team struggled to get the application to behave as required, they became concerned about their ability to complete and test in time for the event. My sponsor and team were at odds over the project schedule and became adamant that their respective interests be accommodated.

As project manager, I needed to address two contradicting positions. First, my team needed to feel that their concern about the deadline was taken seriously. An unheard attitude of “we’re not going to meet the deadline” can become a self-fulfilling prophecy. I didn’t want us to subconsciously undermine efforts to succeed in order to prove that our predictions were right. My team needed to be confident that I was communicating the schedule risk appropriately.

Second, I wanted our sponsor to be confident that every effort was being made. If I simply informed them that we were projecting a schedule overrun, the sponsor would likely have implemented their own strategies to meet the date - completely understandable even if it was a long shot. I communicated status using a blend of progress (what we’ve done) with a qualitative assessment of its impact on schedule risk. Next, I laid out our forecast (what we’ll do), again with prediction of risk impact.

In the end, we didn’t launch at the scheduled event (you thought I was going to claim success?). In a way though, we were successful. The development team had flown to the client site, and both sponsor and team felt that all efforts had been made to meet the deadline. The sponsor was not caught by surprise because they had been kept up-to-date concerning risks all along. Eight hours before the event, the sponsor rescheduled the planned launch, perhaps not thrilled, but satisfied with the team’s commitment to the sponsor’s goal. Everyone ended up on the same page.

Moral: A project manager’s ability to advocate for both sponsor and team makes it possible for those with differing interests to work toward a common goal.

PM Practice: Tips for Tasks

Sorry … I should say ‘activities’ … not tasks. Pardon my non-PMI-speak.
Early in my coaching career, I worked with a bright project manager on developing his schedule. We talked a little about how to create a WBS and then how to define activities. I gave him those steps as an assignment and left him to it. When we met again, I was surprised to discover that he had no idea how to structure work. His activities ebbed and flowed in different directions. Some bore no relationship to the project, while others seemed to bleed into each other. Imagine defining activities for a dinner party. This fellow would have included activities like:

• “Prepare ingredients in the fridge” (what about the ones in the cupboard),
• “Buy and broil meat” (is that all you are buying … and aren’t there a couple activities in there?)
• “Bring salad to the table holding bowl with 2 hands” (the 2 hands part is a specification, not an activity).

Since then, I have thought more carefully about how I actually define activities so that I can talk about it to the less systematic among us (a group I identify with more as I get older). Apart from saying ‘it looks weird,’ here are some tips that have helped:

1. Activities involving performing work. It follows then, that activities should be structured using a verb-noun structure, as in “Do Something.” I worked with an event planning team that included activities like “Hotel.” I asked if they were planning to book it or build it.
2. Team members should be able to agree on what done looks like. Most people would say that “Write Draft Document” would end with an essentially-complete first pass at the deliverable, so that’s a good one. “Conduct Research” is trickier. Adding some specifications as a note to your activity may help.
3. Completing the effort associated with an activity should move the project measurably forward. “Execute Test Plan” should yield a performance result. I saw a plan once with an activity called “Develop Team.” I suggested they change it to “Hold Team Spa Day.” At least you know there’s no going back once you’ve had sweated it out in a sauna with your analyst.
4. Activities can be big or small. There is no hard and fast rule here, but I like each team member to focus on between 1 and 3 activities in a week, plus 1 project administration activity that remains open for the duration of the project. This usually means that activities will range between 8 and 60 hours of effort. Activities that are too small lead to administrative overload when you collect actuals from your team each week (which of course you do …). Activities that are too large are difficult to monitor for progress. “Create Requirements Document” can be a 6 to 8 week process with only 1 measureable deliverable at the end. Without a near-term checkpoint, activities like this long tend to get longer. I was brought into a project once that had spent 12 months on requirements for a supposedly 18-month project. I would break this activity into a set of iterations of draft and review.
5. If the effort transitions from 1 person to another, that’s probably a new task. “Write …” is one task. “Review …” is another.
6. A waiting time often signifies a break in tasks. Keep this in mind with projects that involve paint or concrete.

Activities are foundational to project monitoring and control. Getting a solid model of defined activities for the project will pay off later with fewer gaps or overlaps in scope and the team’s improved ability to deliver to expectations.

PM Practice: Using Milestones

While hiking on a trail outside a Swedish town where I used to live, we passed a milestone on the side of the path. This piece of stone was about a foot wide, 6 inches thick, 4 feet high and many hundreds of years old. There were a couple of features about it that caught my attention.

It was easy to spot from a distance, but it didn’t take up much space. The face of it was inscribed with one number indicating where we were on the path and a 2nd number informing travelers how far it was to the next major town. As we walked along the path, we were either moving towards it or, having passed it, moving away from it. The time that we spent ‘at’ the milestone was maybe a second. The parallels to project milestones make it clear why these ‘moments on the path’ share the same moniker:

• Milestones provide a clear measure of progress and are uniformly visible to all stakeholders. When you pass the ‘Design Complete’ milestone, pencils go down and girders go up. If you’ve still got a pencil in your hand, you haven’t passed the milestone yet.


• Milestones have no effort associated with them. Tasks do. ‘Design Complete’ is a milestone. ‘Complete Design’ is a task.


• Milestones have no duration. They’re just markers on a path. If you stop to marvel at your accomplishments upon reaching a milestone, fine - many people do. But that’s a task (‘Admire Progress’) that has nothing to do with the milestone.


• Milestones are either 0% or 100% complete. There is no ‘50% complete’ for milestones. Once you complete all the tasks needed to reach the milestone, the milestone is passed. Until then, keep working.


• Different milestones may hold the interest of different stakeholders. ‘Key’ milestones are of interest to everyone and often associated with either a major deliverable (‘Test Case Creation Complete’) or a change of the project phase (‘Testing Complete’).


• Milestones are placed with reasonable regularity. I aim for some kind of milestone about every 4 to 6 weeks. Agile Project Management leans heavily on this idea because sponsors need only commit to the process incrementally.


• Key Milestones are on the critical path. As a communication tool for progress, they work better when they don’t wobble around due to float.

Some milestones existing today have been in place for centuries, yet still convey accurate information (Stockholm hasn’t moved). They tend to be stable. Project milestones are similar.

PM Laws: Who Defines Project Success?

When joining a project, I often ask team members to tell me a bit about previous projects. It helps me to understand their perspective on project work ... and keeps me from being (as) surprised later.

I'll ask them to tell me about a successful project and what it was that made it a success. I hear lots of reasons such as a great team, got to use new technology, build what 'I' wanted, requirements didn't change, ... When I ask why the sponsor or key stakeholders thought the project was successful, the confusion sets in. Some team members tell me that the sponsor was not happy with their successful project. More commonly, they simply don't know whether stakeholders considered the project a success or not.

This perplexes me. How is it possible for team members not to know what their stakeholders think about the project? This form of 'tone deafness' is a huge risk for project failure.
It's completely fine to be proud of the work we've done on projects, to enjoy being part of a particular team, or to get a chance to work on something really new. In the end, however, the success of any project will be defined and judged by those that initiated and paid for it. Just keeping this on the team radar goes a long way to ensure that the work being done is moving the project towards success.

So, the project you just finished ... was it a success? Says who?

PM Views: Chaos in Project HR

Finance, Operations, Strategy, R&D, Marketing & Sales, HR, Technology. These are the functional pillars of organizations. I've wandered through the consulting landscape of these areas in both project and non-project organizations, and I have found HR to be far and away the most broken. The ancillary 'personnel administration' aspects of the discipline are fine - things like records and rules are handled as well as anything else in organizations. But the core value that HR can offer - leadership in the getting and keeping of the right people - is abysmal in the vast majority of organizations I've encountered.
Why would this be? The talent management folks I've met are just like other parts of the organization. There are enough inspiring, capable individuals sprinkled among the discipline that it should be possible to do better. Maybe the size of the failure hints at the complexity of the challenge? Think about this:

• There is reasonable evidence that 'superior' work performance can be predicted (though not perfectly) based on a combination of raw mental horsepower coupled with a set of about 20 competencies (e.g., results orientation, resourcefulness, ...). Personality tests may not predict work performance so well, but can provide clues about related factors such as whether your Einstein will show up or not.
• The overwhelming majority of recruitment and selection processes in organizations focus on education, experience, and technical knowledge. The predictive ability of these factors is much weaker than competencies.

It's amazing how often I hear HR staff claim that they need a project manager with knowledge of 'System X' because they need to be able to talk to the programmers on the team. I may be way off base here, but that sounds like a communication competency, not a technical one. I've managed many a project (successfully) where I didn't understand the ins-and-outs of the technology, but I could pick up on when one of my team was concerned about something. In fact, thinking back to my project management failures, it has been on projects where I understood the content deeply - perhaps to the point where I took my eye off the management ball.

So why is HR talent management so completely focused on the wrong things? Competencies are extremely intricate and challenging to assess. It's also expensive, though not as expensive as making the wrong choice for your organization. Experience and technical knowledge assessment on the other hand can be automated (or as I like to say, 'commoditized'). And during high-supply economies like 2009, the push to emphasize throughput over value is even stronger. Unfortunately, a lot of companies are simply missing the best individual faster ... and it peels dollars you don't see right off your top line.

PM Practice: The Right Way to Track Actuals

Most project managers I know track actuals at a task (e.g., 25% complete) or duration (e.g., 4 days spent, 3 days left) level. Effort (or work) is generally left to be managed by their scheduling tool. The method you choose for tracking actuals affects the ability of your schedule to predict final time, cost, or scope. The problems come when PMs use task-level tracking (low predictive power) in order to manage a project where high predictive power is required (i.e., project milestones are 'set in stone').

Effort is the real currency of most all projects. It measures, in hours, the heads-down work performed by individual members of the project team. It is a key determinant for the duration and cost of most tasks. Project managers that track actuals at an effort level are able to sort out what is causing delays or cost overruns because their project data is more granular. When I track actuals in my projects, I can make smaller, more targeted, corrections in concert with my project team. My projects still slip (after all, we only manage risk, we don't control it), but they do so less often, and usually less dramatically (and therefore more correctable).
Tracking actuals at the effort level is just as easy as other methods. I follow these steps:

1. Each week, my team reports ATD (actuals-to-date), in work hours, for any task that was ongoing at some point during the week. I build my schedules such that each team member will typically work on 1 to 3 tasks per week.
2. For each of these tasks, my team also provides and ETC (estimate-to-complete). Obviously tasks that they completed will have an ETC of 0 hours. Steps 1 and 2 take each team member about 5 minutes a week.
3. I set up a tracking view in my scheduling tool (whatever my client needs me to use) that allows me to apply ATD and ETC to individual tasks every week. There are tons of tools that will automate this process, but even if I do it manually, we are talking 10-15 minutes every Monday morning for a team of 30 people.
4. I save my project plan, updated with last week's actuals, and begin my weekly upkeep (a tidy schedule is a defensible schedule I always say!).

I have taught several hundred project managers the nuts and bolts of this process over the years and those still in the job today couldn't imagine not tracking their actuals another way. Anyone can learn how to do this and the impact on project manager performance is a blast to watch. New project managers gain confidence because they develop a better understanding of their projects. Experienced, capable PMs get a real boost from this method because it helps them validate their intuition about adjustments they may need to make.

Agile adjustment: This practice works with Agile, though you may choose to shorten the interval from a weekly timesheet to a daily verbal report of ATD and ETC. Properly measured, tracking effort can help Agile teams compensate for deficiencies in the organizational implementation of the development method ... but that discussion is for another time.

PM Laws: Ascend the Project Knowledge Slope

One of the truisms of projects is that you know the least about your project (or product) at the beginning and most about it at the end. This fact pervades every aspect of projects and how we manage them:

• When making a decision, you will always know more tomorrow. Some decisions are improved by waiting; some benefit from timeliness over gathering more knowledge. It's not always easy to know which is which.
• Budgets and dates are usually established at the beginning when we know the least about projects. There's a good reason for estimating these early, but it does make things more complicated.
• Project documents are intended to help us ascend the knowledge slope. Docs that help teams and stakeholders to learn collectively work best. Boilerplate text doesn't help.
• You may have planned your project expertly, but it will change almost as soon as you sink your baseline. Do you have a system that helps the plan evolve fluidly in concert with your understanding of the project?

The most successful project managers I've met are the ones that run their projects with awareness that they can't know everything from the get-go. Learning and adjusting will be the norm. The ones I've coached who struggle in the job are often railing against this reality. If you refuse to baseline your plan before your requirements are signed off, you're fighting the curve, my friend.

I Like Projects Because I Like Change

Most change needs the coordinated effort of more than one person and projects are the construct for achieving results from our efforts.

By construct, I mean that the word 'project' is simply the taxonomy we use to describe a way of doing something. If someone tells you, "I worked on a big project last year," what are they really saying?

• I was a key contributor to a significant outcome?
• I was focused on achieving a goal in concert with others?
• I suffered under an inflexible regime in order to keep my job?
• What's on the lunch menu today?

Projects can generate strong emotional reactions - both positive and negative. But projects in their basic form are neutral. They are just of way of getting something done. So, how does it happen that some projects earn the nickname 'crowning achievement' where others are called a 'death march'?

I think it's because at their core projects are human enterprises. They contain all the necessary ingredients for both great (hope, dreams, ambition, conviction) and underwhelming (ignorance, prejudice, ambivalence, conviction) achievement.

Projects engage me because they hold so much promise. They can encapsulate achievement, whether it's building a beautiful house, a useful program, or a better health care system. But they're not easy. The world is chock-a-block full of processes, methodologies, tools, dashboards, and all kinds of 'techniques' to help manage projects. But still, they're not easy. That's because success in projects comes from things that are deeper than dashboards. They come from and through … us.

I've been fortunate to make a decent living helping other people's projects work better. It's fun and rewarding and it lets me get to know some pretty talented clients. I know a project team is on the right track when they let go of the idea that their success is measured by some dashboard ("if we code the status yellow, they'll stomp all over us!"), and start to visualize what they could possibly achieve. It has almost invariably been more than the team initially realized!