When I started as a project manager, the focus of my attention was on the mechanics of project management. This involved becoming very involved in work plans, risk/issue trackers, status reports, progress metrics and all those artifacts that form the means by which one manages a project.
What I realized after a number of years (as well as after a few hard learning experiences) was that while the mechanics of project management are important, they are merely enablers for the core activities that truly create a successful project.
I needed to think more about the successful direct and indirect business outcomes that could be created from a project. The attainment of successful business outcomes was what my stakeholders were really looking for, not necessarily the most impressive work plan or status report. This shift in focus become one of the turning points in my project management career.
So how does a project manager, in particular one early in his or her career, make the transition from executing the linear mechanics of project management to producing desired business outcomes? Well, they need to acquire the skills and behaviors that enable business success from projects— hopefully without harmful learning experiences along the way.
Here are four tips for making this transition.
1. Don’t Be Afraid of Business Processes
When I was a relatively new project manager, I spent a lot of time at my desk. This desk time was occupied with working on project management artifacts that if created perfectly would, in my mind, automatically lead to a successful project.
A senior project manager noticed this and encouraged me to spend a fixed amount of time creating project management artifacts, with the remainder of my workweek interacting with stakeholders in the business areas. In fact, this senior project manager arranged for me to work for a few days with some of the employees that were actually executing the business processes that were to be impacted by my project. Those few days of immersion were a great learning experience that it completely changed my outlook on how to run the project.
Today, I still employ the same technique for both myself as well as fellow project managers and team members. Whether it’s working in a retail outlet helping to stock shelves, processing billing exceptions in a call center or spending time in an airliner simulator, the immersion experience is essential to understanding what makes for successful business outcomes from projects.
2. Define Business Success Criteria
Very early in my career, I took what my stakeholders initially shared with me as business success criteria without any subsequent qualification. No surprise that some of the success criteria entailed—“just make it easy to use,” “finish testing by the end of the year” or “do whatever the senior vice president says”—didn’t really indicate a clear path to business success.
As I grew as a project manager, I began to spend more time in the beginning of projects articulating in detail with stakeholders clear criteria for business success. This involved not only understanding current processes by immersion, but also challenging stakeholders on the methods we would use to objectively measure business success. If something cannot be objectively measured, it would be difficult to determine the success of the project.
I also allocated time in the project to build and execute the processes to measure success. By doing so, I had the capacity to create evidence of how the project benefited the business.
3. Understand Your Industry
In my first few years as a project manager at an insurance company, I took every course on project management I could find (this pre-dated the creation of PMP certification). While I became adept at the mechanics of project management, I had no real foundation of business knowledge for the projects I was leading.
On a recommendation of a senior project manager, I took a course on the principles of the insurance business. This course covered the terminology, core business processes and emerging industry trends. I left the course wondering how all of this was going to apply to running projects.
Within two weeks of taking this course, my supervisor passed along a compliment from my stakeholders how much more effective and efficient I was in running their project. This newfound productivity came from the ability to more easily understand the challenges that the project was intended to address. Little did I know that the industry training was a form of business process immersion.
4. Get Comfortable With ‘Design Thinking’
The concept of “design thinking” originated with companies finding out that while project managers thought they were achieving the desired delivery success criteria of being on time and budget, they were not really producing the desired level of business success from projects. These companies began to explore ways of changing the approach in determining business success for a project.
Design thinking gives project managers several approaches to fully qualify the path to business success by techniques such as charting a customer journey, business process brainstorming, business case creation and creative reframing.
All of this opened my mind to going beyond the traditional boundaries of a project to ensure I was going to both define and execute to true business success.
I sometimes long for the days when I ran smaller, simpler and shorter projects whose goal was typically to finish on time and budget. I could afford to relax a bit and strive to achieve a high professional standard in the mechanics of running a project.
But as our projects become larger, more complex and longer in duration, we as project managers have to delegate some of these activities to other people, so we can get on with the business at hand of producing successful business results from projects.
These four things helped me make the transition to achieving business results on projects. What are some of the things that allow you to do the same?
If you're new to project management, you might be surprised to learn that some projects -- maybe some of yours -- do not generate any actual profits.
That can make it difficult to demonstrate how talented you are as project manager and how great your project delivery team is. So, how can you show you've created value if you cannot show revenue or profits as a direct result of your project?
Look at ROI in a different light. Instead of using profits as a benchmark, consider intangible benefits, such as cost-savings that will result from the project, or a positive swing in public relations or team dynamics
My team and I were working on a project that involved automating a conference room. A user could walk into the room, push a single button and the automation would do the rest. The project didn't generate any profit, but the feedback from stakeholders was 100 percent positive: My team had created an environment that worked as advertised and made users' work lives easier and less frustrating. And that translated to a huge upswing in stakeholder influence.
When we needed buy-in on the next project, the stakeholders were more than happy to offer support. They even understood if the project would affect them negatively (i.e. space being unavailable for use during project, or a feature being disabled for a short time). It may be hard to say that stakeholders' good graces (for example) increased by exactly 42 percent, but it's very obvious when your ability to influence them has increased. Things seem to just run more smoothly.
Have your projects generated intangible ROI? How have your project teams benefited from it?
|We hear a lot about how quality can make a project management world full of butterflies and rainbows. But I have a bone to pick with quality.|
C.F. Martin has making guitars since 1833. The company's quality is legendary -- and so is its price.
It was Martin that developed the Dreadnought body style, so called because its size was increased dramatically to boost volume and bass response. The resulting models, the D-18 and D-28, became the standard by which all other acoustic guitars are measured.
Sir Paul McCartney played a D-28 at his recent White House performance. Elvis Presley started off with a D-18 and moved up to the D-28 as soon as he could afford to. And from the time I started playing acoustic guitar, I wanted one.
I finally scraped together enough for a D-28, and my obsession started before I even left the store.
The custom cases are so precisely made that you can't leave the strap on the guitar. So, I bought a quick-disconnect device for it.
Then, my salesman informed me that Martin's lifetime guarantee doesn't cover cracks for guitars because of low humidity. In my home state of New Mexico, that's a problem. So, I bought an advanced humidifier and after-market insurance.
And, of course, I needed new strings. (One does not put medium-grade strings on a D-28.)
The beginning of my enslavement to this highest of high-quality musical instruments had begun.
The first time I used it in public, I was aware of a certain sense of dread. I realized that I was walking around with US$2,300 worth of fragile wood strapped to my torso. Microphone booms, chairs and other instruments loomed dangerously close by. My proximity bubble -- that area around your person where you're not comfortable with others -- had just grown significantly.
In past writings I've been a tad harsh on the quality fanatics, primarily because they can (and often do) place project managers in a position of being vulnerable to cost and schedule variances should high standards prove elusive. Those project managers should take heart: The ultimate consumers of your projects are held hostage to these same high standards, as I have come to realize.
I tried playing my other guitars, but it's too late. I have been spoiled. I have also reached the conclusion that quality has a distinct downside.
|Most of my regular readers know I like to take accountants to task for pretending to be able to deliver cost performance or estimate-at-completion information to decision-makers based on generally accepted accounting principles. But that door swings both ways: Earned value practitioners are also guilty of trying to further their technical agenda using the resource managers' arguments and analysis, which, in my opinion, is profoundly flawed.|
The most prominent of these tactics is to try to justify the cost--or even the existence--of the project management office by running some sort of ROI analysis. This is simply illogical if for no other reason than the ROI calculation pertains to assets, not capabilities.
Less notorious but every bit as pernicious is the tendency of earned value practitioners and accountants to compare the time-phased budget's basis of estimate document with its associated actual costs at the line-item level.
In the earned value world, comparing budgets to actuals is worse than useless: It's actually misleading.
And yet, some practitioners seem to think that if such an analysis were simply done at a very detailed level, it would suddenly become relevant. It doesn't.
Oh, they may try to make some lame argument about the need to benchmark the estimators' work, but this assertion lacks validity that can be demonstrated in the following scenario:
A US$100,000 task is estimated to require US$25,000 in heavy equipment and US$75,000 in labor. At task end, US$74,000 was spent in heavy equipment and US$25,000 was spent in labor. An earned value management system correctly--would not raise the red flag for cost performance, but the system that compares budgets to actuals would erroneously report a severe problem--never mind that the task came in under budget.
Any management information system that reports a phantom cost performance problem isn't good for very much.
Next up: The absurdity of maintaining milestone lists in lieu of real schedules.
|I've been covering project management for nearly three years now. I've learned many things about scope creep and schedules and budgets. I know intimate details of some of the world's most extravagant projects (usually in Dubai, United Arab Emirates) as well as some of more mundane ones--both types equally important to their stakeholders, of course.|
What I've also come to learn is the ways project management can be implemented into everyday life. Whether it's planning a party or publishing a magazine, life sure can be made easier with a project plan.
Here at PM Network, our project manager has the title of managing editor. He builds and monitors the schedules, prioritizes work and makes sure all members of the team are communicating any problems that may delay our final delivery. It's a role that takes patience, for sure, because in the world of publishing something inevitably always comes up.
You don't always have to have the title "project manager" to use project management to deliver value.