3 Steps to Outsourcing Success
Nontraditional Project Management,
PM & the Economy,
Categories: Benefits Realization, Best Practices, Change Management, Complexity, Innovation, Innovation, Leadership, Leadership, Lessons Learned, Lessons Learned, Nontraditional Project Management, PM & the Economy, Program Management, Project Delivery, Project Failure, Project Planning, Project Requirements, Risk Management, ROI, Roundtable, Stakeholder, Strategy, Teams
By Peter Tarhanidis
When leaders use outsourcing it is often in an effort to enhance the organization’s value proposition to its stakeholders.
Outsourcing allows leaders to focus on and invest in the firm’s core services while using cost effective alternative sources of expertise for support services.
When services are outsourced, management and employees need to prepare for a transformation in organizational operations—and project managers must establish a strategy to guide that change.
Creating an Outsourcing Strategy
Project managers can help to create an effective outsourcing strategy based on a three-part structure:
1. Assess the current state
This assessment should define the firm’s:
2. Consider the “to-be” state
The to-be state should be designed based on a comprehensive evaluation and request for proposal, including a good list of best alternatives to negotiated agreement items.
The to-be state must consider:
3. Consider the governance required to sustain the future state
A new internal operating model needs to be formed. This includes establishing teams to manage the contract, such as senior sponsorship, an operational management team or a vendor management team.
Then the outsourcer and the outsourcing organization should focus on continuous improvements that can be made to the process.
Avoiding Outsourcing Pitfalls
Project managers can avoid a few common pitfalls in their outsourcing projects:
Overall, if done with a defined end in mind, leaders can capitalize on outsourcing by reducing operational costs, reinvesting those savings in core services, and providing access to expertise and IT systems that would normally not have been funded via capital appropriation.
Have you been a part of any outsourcing efforts? What advice would you offer to project managers involved in similar projects?
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?
PMBOK® Guide for the Trenches, Part 6: Quality
| 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.
Practitioners Versus Accountants on Earned Value
| 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.