Author: Kevin Aguanno

I was sitting in a project team meeting yesterday where a group of us were trying to figure out the right strategy for dealing with a difficult project sponsor.  The issue was that the scope of the project was constantly changing and we were being rebuffed by the sponsor when we tried to point out that our requirements gathering and analysis budget was already spent, yet new requirements were popping up daily.  The sponsor was saying that they need all of their requirements documented and the impacts on the solution design analyzed – which is correct; however, the sponsor is not willing to reallocate funds from the solution build budget to the requirements budget, nor is he willing to discuss adding funds to the project overall budget.        

To make matters even more difficult, the last time we approached the sponsor to make him aware of the impact of this ongoing requirements churn on the project budget and timeline, he escalated to our sales team to complain that we were upsetting him and not doing our proper jobs by managing the project within its constraints.  The sales team members in our meeting (who own the overall customer relationship) were insisting that we find a way of continuing the work without highlighting the budget issues.  In essence, they were arguing that we should hide the fact that we are going to use up so much of the overall project budget during this requirements churn that there may not be enough left to build a viable solution.  They were telling us not to speak with the sponsor further on this issue.

While this was going on, I heard the chorus of a song by Des’ree running through my head:

You gotta be bad, you gotta be bold

You gotta be wiser, you gotta be hard

You gotta be tough, you gotta be stronger

You gotta be cool, you gotta be calm

You gotta stay together…

I was immediately struck by how these lyrics could have been written for a project manager.

Being strong and tough while still keeping a calm and cool demeanor would be very useful in our situation.  We needed to stand up to the salespeople while not seeming to be unreasonable and too confrontational or difficult to deal with.

So, I took a deep breath, gathered my courage (was bold), and I started to push back (was tough).  I used logic (wisdom) to highlight the negative outcome of their approach.  I did not let their numerous interruptions and attempts to redirect the conversation divert me from explaining my position (was strong), and did all of this in a calm, level-headed (cool) manner.  Basically, I followed the advice of the song.

The delivery team was behind me and soon heads were nodding and supportive comments were coming from all members of the group.  They saw what I saw and were equally concerned about getting the project back on track.  All they needed was someone to follow, someone to stand up and lead them into confronting the dysfunctional approach promoted by the salespeople.

The more astute of the two salespersons quickly dropped his argument when he saw that the majority were behind me and that my arguments held up against their objections.  He eventually sided with reason and good practice.  The other salesperson continued to push his own dysfunctional approach for a while until he realized that he was the only holdout in the room.  At that point, he quickly changed his approach to match ours, but tried to make it look like our approach was his idea all along.  I wasn’t concerned about who got the credit for the idea – my self-esteem didn’t need the ego boost – so I let him save face by claiming credit in front of the group.  (It really didn’t matter, since they all saw how things had unfolded; he wasn’t fooling anyone but himself.)

In the end, if all worked out. The salespeople agreed to the approach that the team had initially proposed.  They agreed to meet with the sponsor and explain that the requirements churn on the project was consuming solution development funding and that he needed to be aware of this.  They agreed to propose that the project pause for a while until the sponsor can decide what to do about all of the changes being proposed by the various involved stakeholders – after all, the budget can only accommodate a small fraction of the work required to build a solution which  meets all of the newly-emerging requirements. They also aggred to get the sponsor to formally sign off on a re-allocation of funding or additional funding before the project resumes.

I guess it pays to be bad, bold, wiser, hard, tough, stronger, cool, calm and together.

Don’t forget to leave your comments below.

I once heard the president of a large company say that sales people were important because they increased the revenues of the company but that project managers were more important because they turned those revenues into profits.  And those profits, he noted, drive an increased share price (the value of the company in the marketplace).

If we as project managers are responsible for the creation of a company’s value, then we have a professional obligation to perform that job well, as the converse would also be true:  project managers performing poorly can also destroy a company’s value.  How do we perform our job well?  To answer this, we need to look at which project management activities have the greatest impact on achieving the project’s desired outcome, as valued in the business case.

I personally believe that the two most critical contributors to achieving project business case outcomes appear at the start and end of our project lifecycles:  good requirements analysis, and the strategic application of testing activities.  The two of these combined ensure that the project is focusing on creating the right outcomes and that the project is verifying or demonstrating that the outcomes have been achieved to ensure the delivery of optimal business value.

The key concept here is “optimization.”  Yes, many project activities drive value.  Some, however, have an incommensurate effect on the total business value delivered by the project when it is completed.  By conducting a Pareto analysis of the most common project activities, we see that creating the right outcomes (proper requirements analysis) and ensuring that those outcomes are achieved (proper testing) have the highest business value to effort ratio.

Of the two, I believe that testing gives you the biggest lever.  Yes, proper requirements are important, but typically requirements-related activities are only a small portion of the overall project activities and happen at the beginning of a project when everyone – including the business people involved – understand the project environment the least.  Testing, however, happens mostly near the end of a project where there is much less uncertainty about what are the desired project outcomes.  Testing activities (and the related defect correction efforts) are what determines whether or not the project has been successful.  If inadequate testing is performed, then the outcomes created earlier in the project will not drive the proper (or possibly any) business value.  Quality assurance (testing) is one of the most critical activities for achieving project success.

Similar to under-testing, there is a danger of too much testing, too.  We need to find the balance between additional testing and the delivery of an equal (or greater) proportion of business value.  At some point during the testing process, additional testing effort will not create enough additional business value to justify the extra expense.  A strategic approach to testing needs to be considered by the project manager when creating the initial project approach.

Here is where another Pareto analysis may come in handy.  Consider all of the types of testing that we can perform on a project:  usability testing, accessibility testing, performance testing (including load and scalability), functional and systems integration testing, disaster recovery testing, etc. – on an individual project, some of these will drive more value than others.  We need to consider the business case behind the project to know which types of testing will drive the most business value.  For example, perhaps a given project requires rock-solid 24×7 performance or else the business will suffer; in that case, disaster recovery testing may drive a measurable amount of business value, while it may add little value in other, less mission-critical projects.  We cannot take the same testing approach on every project – we absolutely need to tailor our testing activities to the individual needs of each project’s business case.  In other words, it is essential that we consider testing strategy when we begin planning our project.

So, when that company president said that it was project management that drove business value, I believe that if we had the chance to dig a little deeper discuss what was underlying that comment we would have heard that the project manager’s responsibility for project value includes building the right things and then verifying that those things meet the business case needs.  And a disciplined focus on testing strategy will ensure that the project has created the planned business value, with the right test strategy ensuring that these validation activities have been performed in an optimal manner.

Don’t forget to leave your comments below.

As it is January, I thought it would be a good time to share with you my project management New Year resolution.  But before I share it with you, I want to share an observation: if I could make up my own personality categorization system for project managers, I might say that there are two main types:  builders and maintainers. 

Builders are the project managers who love to manage projects that create brand new things:  shopping malls, online courses, software applications, new products, etc.  They are excited by the unexpected challenges they will face and thrive on the creative energy generated by the team.

Maintainers are those project managers who prefer projects where there are fewer “unknowns” and perhaps an overall lower risk profile.  These are projects updating, renovating, or maintaining existing products, buildings or systems rather than creating new ones. These project managers focus on optimization and efficiency as their main goal.

I would imagine that the New Year resolutions of these two types of project managers would be very different.  New Year resolutions tend to say that we will begin exhibiting some positive behaviour that we probably should be doing now but aren’t, or that we will stop a negative behaviour.  Builders (who are more interested in tackling challenges like project issues than in standard administrative processes) may have a resolution saying “This year, I will begin updating my project financial tracking spreadsheet weekly instead of monthly, just before the deadline.”  Maintainers (who tend to be more interested in using metrics to optimize the project process than in dealing with broadly-defined but imprecise strategic directives) may have a resolution saying “I will take the time to perform a formal stakeholder analysis at the start of all of my new projects, and will use this information when I craft the project approach.”

Now, let’s be practical.  I know that we should probably be doing all of these things all the time; however, in the face of day-to-day project pressures, and the common problem of not having enough hours in a work day, we have to let something slip.  What that may be depends upon our organization (what they measure), our project (what our customer wants), our team (how much direction they need), and our own personality (Builder or Maintainer).  The situation is not as simple as I may have made it sound above; however, I think that a project manager’s personality does have a strong influence on his or her choice of a project management New Year resolution.

My resolution:  to spend more time following up on action items assigned to team members.  I expect that, since we spend so much time trying to hire the right people for our organizations, that we have a pool of reasonably skilled, competent, and motivated people from which to draw our project teams.  I expect that people will keep their commitments, never lie, and generally try to cooperate with others on the team.  Basically, I expect everyone to act as professionally as I do myself.  Maybe this is a little too naïve – I have had a few disappointments over the years where others fail to live up to my standard – but I believe that most people mean well and will try to do their best.

My resolution will help me avoid some future disappointments by identifying those who are not meeting their commitments early on so that I can take action to avoid any major issues occurring.  It is easier to fix problems while they are still small ones rather than avoid them until it is too late to resolve them.

Based on my resolution, I am sure that you can guess my own project management personality type.  I am a Builder.  That means that I like dealing with “fuzzy” situations, project strategy, stakeholder relations, and project issues but I am less excited about the administrative side of my job:  issuing status reports, reviewing time sheets, financial tracking, sending out meeting minutes, etc.  Yes, I do these tasks, but to me they seem like chores – not something I look forward to doing, and a candidate for procrastination in preference for more exciting project challenges.

This year, I plan on focusing a bit more on the administrative side of my job.  I must find a way to make these activities seem fun.  Maybe I can “psych” myself up to looking forward to these activities.  Maybe I can repeat a mantra ten times each morning:  “I can’t wait to start working on this week’s status report!”  No, I don’t think this is working for me.  I guess I’ll just have to bear with it and force myself to do the work.  No one said project management was all fun.

Don’t forget to leave your comments below.