Author: Dian Schaffhauser

Dian Schaffhauser is MPUG's editor. She's been covering project management, business transformation and topics technical as a journalist and editor since IBM released its first PC. She invites you to send your best story ideas for MPUG to her at editor@mpug.com. She promises to let you know what she really thinks.

Survey: Reporting Bad News about Projects

Bad news with projects abounds. More than nine in 10 project managers (94 percent) have had to deliver bad news to managers or executives in the last year, according to a recent, online survey hosted by MPUG. So it’s probably no wonder that people managing projects also consider themselves fairly expert at delivering bad news. On a scale of one to five, respondents rated themselves on average at about 4.3. Although the results of the survey were non-scientific, they still provide insights about how project managers who consider themselves experienced in delivering bad news do the job. Bad News on Projects = Schedule Delays Bad news doesn’t follow a single track. In fact, most project managers reported on bad news with many facets. However, in almost every case the bad news had to do with schedule delays; 88 percent of the time that was what needed to be reported. Almost half the time (reported by 49 percent of respondents) there were budget overruns and nearly as often there was scope creep (reported by 46 percent). In a third of the situations (37 percent), lack of communication was at the heart of the problem. Other, less common activities were staff disinterest (12 percent) or sponsorship pullback (seven percent). Respondents also noted bad news related to the product not working as intended or not being accepted by users, vendor issues and lack of resources. What kind of bad news was reported [ezcol_1quarter] Schedule delays Budget overruns Scope creep Lack of communication Staff disinterest Sponsorship pullback[/ezcol_1quarter][ezcol_1quarter] 88% 49% 46% 37% 12% 7%[/ezcol_1quarter][ezcol_1quarter][/ezcol_1quarter] [ezcol_1quarter_end][/ezcol_1quarter_end] Reporting Methods and Response The face-to-face approach is the preferred method for reporting bad news. Two-thirds of project managers (68 percent) used that means to deliver their grim update. Email was the next most common method, used by 39 percent of respondents. Other means included via virtual meeting (29 percent) and to an individual person (29 percent) and by phone (12 percent). Along with the information about the project problems, project managers were also likely to offer solutions too. In the most recent example of having to deliver bad news, three-quarters of respondents (76 percent) said they or somebody else proposed a way out of the dilemma as well. The way managers and executives responded to the bad news in that latest incident was all over the emotional spectrum. The most common response was frustration, reported by 44 percent of respondents. A third of senior people (37 percent) reacted by giving advice. Three in 10 (29 percent) responded with “calm.” And two in 10 (17 percent) got mad. How managers and executives responded to bad news [ezcol_1quarter] With frustration With advice With calm With anger With a solution different from the PM’s With no reaction at all With a solution With humor Other[/ezcol_1quarter][ezcol_1quarter][/ezcol_1quarter] [ezcol_1quarter] 44% 37% 29% 17% 12% 12% 10% 10% 17% [/ezcol_1quarter] [ezcol_1quarter_end][/ezcol_1quarter_end] One manager told the person delivering the bad news that the proposal “was well prepared,” another agreed with the PM’s suggestion, and a third leader offered to assist in removing “any barriers” if needed. Then there are the bosses nobody would choose to have. One person said the executive came back with “warnings that the new solution must work.” Another felt “hurt because he was the inventor of the product.” And one responded with blame, “although I had negotiated a no-cost solution with the vendor.” Advice for Delivering Bad News Nearly everybody shared advice for delivering bad news. If there were a way to summarize the guidance, it would be this: Communicate unwelcome information as soon as possible, without emotion, face to face and in person, with an explanation about what happened and a solution or two in hand. “Be open and honest about how the situation came about and how to resolve the issues,” said one respondent. “Provide options for the path forward and ask for other solutions to the issue. Admit to internal mistakes. People seem to be much more reasonable when they understand the situation.” Another project manager suggested the bearer of bad news do so in an executive meeting “with your customer beside you, supporting your solution.” “The news is the news,” noted one person. Deliver it, “unapologetically, directly and dispassionately.” Then be ready to “move on to discuss what might be done to recover or act in accordance with risk plan.” Even if you’re not sure about the viability of a possible solution, propose it anyway to jumpstart discussion, added one PM: “It may not be the final solution but it will at least get people thinking of how to tackle the issue.” Alison Sigmon, author of Delivering Bad News in Good Ways who has also written and spoken for MPUG on the topic, offers her own advice: “What happens before giving bad news is just as important as the discussion and follow-up. Acknowledging your feelings and your thoughts, evaluating options and considering your plan going forward for that conversation will go a long way to [determining] how well the conversation goes.” Have your own advice for reporting the bad news? Share it with MPUG readers in the comments below.

Survey: PMOs Have Room for Improvement

Project management offices are there to take on the big project work within an organization. For example, the most important job for the PMO is to oversee project reporting and communications. Job two is doing project portfolio management. And third is defining and maintaining project management best practices and standards for the organization. Those results come from a recent online MPUG survey on project management offices, taken among project managers, almost all of whom (87 percent) work within a PMO. When asked to choose the three most important duties from a set of seven, 90 percent chose overseeing project communications in one form or another; 80 percent selected project portfolio management; and 63 percent picked defining and maintaining PM standards. Those dominated far and above other types of PMO responsibilities, including overseeing budgetary aspects of projects (37 percent), evaluating and adopting project management tools (23 percent), addressing specific project management problems (13 percent) or training and certifying project managers (7 percent). Respondents also suggested additions to the list. Some recommended that the PMO should “lead by example,” and others said the PMO should administer project management tools. Just one in 10 respondents believes that his or her PMO is “completely effective” in meeting its duties. Most survey participants stated that they considered their PMOs either “mostly effective” (39 percent) or “somewhat effective” (35 percent). The remainder consider their PMO “barely effective” or completely ineffective. In an open-ended question, PMs were asked to list what area of professional development their PMO could best benefit from in helping them achieve goals. A solid third of respondents said their PMOs could do with some training in leadership skills. Half as many said communication was worth more attention. And a smaller number designated reporting. But the suggestions didn’t end there. Individual respondents recommended additional training in these areas: Agile software project management; Costing techniques; Risk management; Learning how to show the value-add of the PMO; Developing standards; Governance accountability; People skills; Career and training; Helping people understand the differences between project and program management; Scheduling techniques; Standardization methodology; and Strategic planning. Then there was the respondent who (rather mysteriously) would like to see the PMO learn how to “cull the MBA community humanely.” In a similar question, MPUG asked PMs for one improvement they’d make in or to their PMO if given the opportunity. While several suggested getting better at communication or reporting — a continual theme among this crowd — others would like to see advancements in project intake, resource and schedule management, risk management and governance. And still others would like to improve certain activities, such as doing data visualization, reducing the number of policies, or getting better at metrics or project finances. Another common theme was getting better corporate recognition, whether to better communicate standards outside of the PMO, enable senior management to recognize the need and value of the PMO, gain more “visible” responsibility, evolve into an enterprise PMO, or change whom the PMO reports to (preferably, the COO or CEO). Some respondents focused on people: locating the team under one roof, populating the PMO with people “who have project management experience” or persuading staff to get certification in PMO operations akin to PMI’s PMP. (Such a formalized credential doesn’t really exist yet.) And then there were those who were more ambitious in their suggestions, such as the individual who would like to see the PMO develop a “more client-focused service ethic” and the respondent who would like to see one “consistent methodology for business and IT.” While PMO mileage obviously varies from one organization to the next, one conclusion that surfaces from this survey of those who work within PMO operations is that the traditional view of the PMO as a beacon for project management enterprise-wide is naïve. Just as the best project managers are continually on a journey to improve their skill sets, PMOs too need put effort into improvement to become the kind of center of excellence or guiding light their companies need. What does your PMO need to do to meet your qualifications for “excellent”? Tell the MPUG community in the comments below.

Scheduling Master Tom Henry on Why We Shouldn’t Run Projects in Our Heads

Tom Henry a senior consultant at Campana & Schott, spends his weeks implementing enterprise project management systems for clients in multiple segments and training them on how to get the most out of their solutions. During the Microsoft Project Virtual Conference 2016, which ran in February, 2016, Henry shared “tips, tricks and scheduling best practices with Microsoft Project.” MPUG also asked him for a brief preview.   MPUG: Tell us something about scheduling that we may never have thought of. Tom Henry: It gives you clear insight into projects. If you think about it, when you’re running a project, you probably have a hundred things you’re thinking about all at the same time. You may have written them down, but you can’t truly understand when these things can physically take place. By using a scheduling tool and inputting all the tasks into a project schedule and then putting logical ties between the tasks within the project and letting Microsoft Project schedule everything out for you, so you can really get clear insight into when things can possibly happen. You gain insight you couldn’t possibly have worked out in your head. If something changes, you can input that into Project. It tells you what’s affected and what things are now going to have to be pushed, and you can take corrective action accordingly. Where do you like to advise clients to start when they’re building a schedule, and does that vary depending on the project? I always say to people, keep it very simple. This is a project schedule; it is not the actual project. This should be a model of the project, and a model is usually a simplified version of something. Make sure it’s concise. Put as much information as you need, but as little information as you can get away with. Don’t try to micromanage things within the schedule. Keep it high level so you can understand it and it helps you. We’re curious. How long does it take you to build a typical project schedule? It depends on how big it is, but typically about an hour. That quickly? Yeah. But I’ve been doing this for five years. And I’m usually doing repeatable projects. If I were doing something from scratch, it might take longer, where I really have to think about all the different steps and things I might not have thought of before. When the project schedule is off track, where do you advise people to begin their forensic work to uncover the source of the problems? When a project is off track, what you need to do is take a look at the baseline. Within Project use a table view to see a whole bunch of different columns showing you what the variance is on each task. That tracking table will show you where you’re ahead of schedule and where you’re behind. From there, you take corrective action.   Image Source

How Enterprise Social Collaboration Can Get You Over the Project Wall: An Interview with Ken Winell

Last October, a few months after Ken Winell had joined Tough Mudder as vice president of technology, he found himself wading through the mud, risking electrical shock and pulling himself over walls in what has become the company’s wildly popular signature extreme obstacle course. Some projects may feel just as extreme to their participants. Winell believes that enterprise social tools such as Microsoft Yammer and Salesforce Chatter will enable project managers to respond more quickly to changing conditions. In his presentation during the Microsoft Project Virtual Conference, Winell showed project managers how to integrate new kinds of collaboration elements into their PM practices to shape projects more effectively. In this interview, he explains why project managers should care about the new breed of enterprise collaboration tools. MPUG: In your virtual conference session you’re going to be talking about newer collaboration tools such as Chatter and Yammer. Why would project managers care about those? Ken Winell: The business landscape continues to change from a collaboration perspective. The studies are all saying that by 2018 50 percent of emails will be more emoji-like than they will be text. Social commerce and social collaboration are going to be key focuses in being able to understand your customer base and, more importantly, being able to understand how they communicate with the cohorts you’re doing business with. The idea in this session is to go through the principles of collaboration and what you need to know with respect to enterprise social management and how that ties into standard IT systems and the ability to actually leverage that data — measuring sentiment, for example — just like you would with any social media property like Facebook or Twitter or Snapchat. Yammer and Chatter give you the opportunity to have secure conversations outside of your email so that people can see the context of how things are done. You can watch the thread while talking about the customer and looking at the customer data. There are a lot of things that come into play here. Some organizations turn on Chatter or Yammer and then it fails. The reason is that they have not thought through the rules of how to set it up and take advantage of it. It becomes very important to understand the rules and the etiquette. At a recent conference I attended, I had the chance to talk with a lot of project management leaders. When I asked them what skill they’d most like to see in their new hires, almost all of them said better listening skills. Any thoughts about how enterprise social tools can help with that? Sure. The whole idea is that listening and active listening becomes a two-part thing. I’ll be on a virtual conference and people might be listening to me talk, and at the same time they could be having a conversation with their friend: “What do you want to do about dinner tonight?” or “Hey, I don’t agree with him. What do you think?” The idea of being able to actively listen using social enterprise tools is that you can have the conversation and it can sit outside the realm of the interactions you have with the other business users. From a project management perspective, if somebody assigns you a task or work breakdown structure or something you need to get done, you’re actively assigned to that. The enterprise social structure will allow you to get the context of it and ask questions of other people like, “What is the best way to go about this?” without telling the boss that’s how you’re doing it. How do you build the use of digital collaboration into your project plans? First and most importantly, understand the business context. This is the big takeaway I would give everybody: Project management is no longer just the way to get the business requirements met. Project managers must be part of the business. The discipline has to be there in order to get things done. Therefore the ability to integrate social and digital tools to allow visibility, transparency, honesty and the ability for feedback are all critical components in the success of any project. When you’re planning your project, you want to deploy very quickly. Let’s use the example where you have your project plan and you have a Gantt chart and dates and milestones and assignments and resources, and that’s great because people can very clearly see what tasks each person is assigned and they can see the dependencies between those tasks. But the questions about those tasks and the conversations that need to go on about that project plan can all be integrated into Yammer and Chatter. You could ask a question: “What does everybody think about this task? Is this the right task to do?” Having those honest dialogs integrated directly into your Gantt planning is going to help you manage risk and keep the dialog going. You’re reading that in real time and communicating directly with the audience and everybody is participating. You’re not waiting for a weekly or daily or hourly status report. There’s a whole level of transparency that doesn’t exist in the old school. This really sets the stage for ultimately being successful in your project delivery. Image Source

Ben Howard on Managing New Product Development

Ben Howard has spent a career in implementing complex enterprise solutions for organizations around the world, earning him his Most Valuable Professional credential from Microsoft. He currently heads his own consultancy, Applepark, in the United Kingdom, which specializes in Microsoft Project Server deployment and training. During Microsoft Project Virtual Conference 2016, Howard led two online sessions; a session on managing new product development with Project Online and a 3-part series on Microsoft Project 2016 essentials.  Recently, Howard spoke with MPUG about why Project beats out Excel when it comes to managing a project schedule and what the biggest challenge is when it comes to managing new product development specifically. MPUG: You’re going to discuss Project 2016 essentials and how to get started with the program. Who is that session intended for? Ben Howard: It’s intended for anybody who might end up managing any sort of project. It’s not necessarily a project manager. You might be an office manager, an architect, a developer — anybody who just needs to get a project done, somebody who needs to manage a project as a part of a day-to-day role or even as a one-off. Why wouldn’t these folks just use Excel? Excel, of course, is a great tool. But what Excel is really good at is playing around with numbers, representing numbers in some sort of way. It’s not a scheduling engine, and that’s what Project is, a scheduling engine. If you put all your activities in — this action is going to take two days, that one will take half a day — and you put all of those in sequence and then you change something, you can see the impact of that change in the subsequent tasks for the project. Project is a scheduling engine that allows you to predict what is going to happen in the future based either on what has happened or what you’re planning to have happen. That’s what Project does exceedingly well. And that’s what Excel does not do. That’s why you should use Project. You’re also giving a session on how to manage projects related to new product development. Can you share one of the biggest challenges you’ve seen in managing projects related to new product development? There are lots of challenges with new products. The biggest challenge is around delivering them on time. Ultimately, you sell them. It’s a revenue model, and therefore you end up with lots of focus in the organization. If you think about many products, there’s a sweet spot for introducing it into the market. If you’re 18 months late in delivering a new mobile phone, you’ve just missed your whole market. So I think the real challenge with new product development is around time limits. It’s about getting a product to market that’s good enough for that market within the right timeframe. Does Microsoft Project Online have some unique capabilities that are especially useful for managing this type of project? Project Online is the whole Microsoft Project Server suite, hosted within Office 365. We’ll cover that as part of that session. If you think about new product development, it’s a whole team effort to get a new product to market. Project Online enables us to use something called the “project workspace,” which really allows a collaboration around the project. Not only can we see that project schedule, but we can see the critical path and manage any issues or risks. We can store all of our project documents. Rather than just sending emails, we actually have a collaborative workspace where everybody who is associated with the project can have input into that workspace and see all the latest documents, test results and market analysis and all of that. It goes a whole step further than just creating a nice project schedule for our new products. Image Source

Steven Squyres Doesn’t Mind Failure: An Interview with the Scientist behind the Mars Rovers

Even if you don’t know who Steven Squyres is, you know about his work. Currently a member of the physical sciences faculty at Cornell University in New York, Squyres, and his team members worked for a decade to develop a proposal acceptable to NASA that would allow the space agency to put “roving geologists” on the surface of Mars. The result was a pair of humble-looking rovers — Spirit and Opportunity — that resembled decked-out props from a Star Wars movie set. They launched toward Mars on June 10 and July 7, 2003 and landed six months later, on January 4 and January 25, 2004. The original goal was to drive each rover for about 44 yards in a single day and operate (from earth) an array of science instruments to examine the planet’s rocks and soil. At most, they were expected to last for 90 days. Remarkably, the scientists behind the project were able to continue communicating with Spirit until March 22, 2010. And Opportunity is still doing its job 12 years later and 26.5 miles from its original landing spot. Squyres shared the amazing details behind this “ultimate project,” during the keynote session of MPUG’s Microsoft® Project Virtual Conference 2016. This event, which featured over 40 live and on-demand virtual sessions about all aspects of Microsoft® Project, is free to all MPUG members on-demand. Every training session earns you a certificate of completion as well as PMI® professional development units (PDUs). Recently, Squyres spoke with MPUG to explain why he’s okay with failure, what one of his biggest project challenges was, and what he really thinks about the movie, The Martian. The initial idea, from what I understand, was to create a robot geologist. What could that achieve that a bunch of photographs couldn’t do? What we wanted to learn was whether Mars was once a planet that would have been capable of supporting life. Was it once a habitable world? Mars today is cold, dry, desolate. It’s a horrible place. But there were these intriguing hints that we could see from orbit that it might have been warmer and wetter in the past. What we wanted to understand was the details of that. What we wanted to do was really do geology. Geology is sort of like a forensic science in a sense. A geologist is like a detective at the scene of a crime. You’re looking for clues to tell you what happened someplace a long time ago, and the clues are in the rocks. Every rock will contain in its details, in its texture, in its chemistry, in its minerology, information about the conditions under which it formed. Since it’s a nice, sunny, blue-sky day here in New York, I could take you on a walk here in some of the gorges of the Cornell campus and we could look at the rocks in those gorges and piece together from the details of those rocks a pretty comprehensive story of what it was like to be in this part of the world 350 million years ago in the Devonian period when those rocks were laid down. If you can get down on the surface, if you can touch the rocks, if you can look at them up close, if you can measure what they’re made of, you can learn what it was like in the past in a way that you can’t simply do with pictures from orbit. So the little wagons you had come up with were intended to be able to manipulate the rocks? They were intended to investigate the rocks. What I’d like is to have a human geologist there. Human geologists have all sorts of capabilities that these Rovers don’t have. But given the schedule, given the budget, given the technical realities, the challenge that we posed for ourselves was to build the best robot geologist that we could and try to go and answer those kinds of questions. Is it true that NASA actually rejected your proposal? So many times. I spent 10 years writing a series of proposals to NASA to do something like this mission. Each one shot down in turn like so many clay pigeons over a period of a decade. Honestly, I’ve still got all those proposals. In fact, most of them are sitting on my desk behind me. I can look at them now and I can see the flaws. And the process by which NASA decides how to spend hundreds of millions of dollars to investigate other planets is infinitely competitive, as it should be. I can look at those old proposals, and I can look at the things we did wrong, and I can look at the lessons that we learned and how we made things better, and I can see why on our fourth try we finally got selected to do the job that we got to do. But it’s a very intense, Darwinian sort of process. It’s not a whole lot of fun once you’re going through it. and you’re getting all that negative feedback. But in the end, what we came up with was pretty good, and its quality had been honed by having gone through that intensely competitive process. I know we’re going to hear a lot of detail in your presentation. But can you tell us about some challenge you faced in the Rover program and how you overcame it? Once we actually got selected to do the job, there were all kinds of challenges. The most severe challenges, I think, really had to do with landing on Mars. There’s no runway, no landing pad. It’s just a rocky, bumpy, dirty, windy place. And trying to build a landing system that would safely get our precious vehicles down onto the surface in one piece was really tough. When you arrive at Mars, you hit the top of the Martian atmosphere going Mach 27 — 27 times the speed of sound. And you have to come up with a system that will bleed off all that kinetic energy, slow your vehicle down and safely deposit it on a bumpy, hilly, rock-studded surface. That’s kind of hard. The scheme that we used was actually derived from a landing approach that had been used successfully some years before on a mission called Mars Pathfinder. We had to go and redesign a lot of the stuff, but basically it used a heat shield to slow you down ’til you get to a nice leisurely Mach 2. Then you throw in a supersonic parachute that would slow us down to a few hundred kilometers an hour. And then we fire rocket motors and inflate air bags and we let the air bags fall to the surface. They bounce and roll and roll and roll as much as a kilometer before they come to rest. And then you have to retract the airbag, open up the lander, and then Rover is all folded up inside and has to do origami in reverse to turn itself into a Rover. It was fiendishly complicated process. And we had many, many, many horrifying test failures along the way. We were exploding parachutes, bursting air bags. There were lot of really bad experiences along the way. In the end we got it all to work, but it was not for the faint of heart. Was that one of your creations that the Matt Damon character, Mark Watney, in The Martian was supposed to have dug out of the sands? No. That was the Mars Pathfinder. That was the mission that preceded ours. Did they get some of that stuff right in the movie? I enjoyed the movie very much. I can quibble with some of the details. The movie was largely shot in a place called Wadi Rum in Jordan. And I’ve been to Jordan. I’ve been to Wadi Rum. I’ve been to Mars — virtually. This looked like Jordan. It didn’t look like Mars. But what I loved about the movie and what it fundamentally got right was the NASA that I saw in the movie was the NASA that I know. That we-can-get-it-done spirit — it rang true. The way that people behaved, the way they handled challenges — it had the ring of truth to it, based on the years and years and years I’ve spent working with NASA. That part of it, it got so right, that other quibbles about wind velocities and rock distribution on the surface are completely forgivable, as far as I’m concerned. Last question. You’re going to have a lot of people who use Microsoft® Project listening to you speak. Did any of your projects with NASA use Project? Ohmigawd, yeah. Sure. We definitely used it for tracking schedules and Gantt charts. The business of getting all of the pieces of the Rover together — I describe it as being like the tributaries of a river flowing together. You’ve got individual little piece parts, and those pieces of parts — they get tested. And then they go onto an electronics board and those get tested. And then they go into assemblies, and they get tested. And you put it together piece by piece by piece by piece. This isn’t assembly line stuff. Everything is a one-off. Everything is a one-of-a-kind. Tests fail, things go wrong, and that pattern of tributaries has to shift to accommodate the delay, to accommodate this problem or that problem. It’s all got to be done by the time we get to the launch pad because we’ve got a three-week-long launch window. If we don’t reach that window, we don’t fly. So the project management challenges that we faced were immense, and the tools that we used would be familiar ones to you. Artist portrayal of NASA rover courtesy of NASA/JPL/Cornell University.

Get Your Project Back on Track

Mitzi, a portfolio manager with a regional insurance provider, was sent into a project that had been underway for a couple of years. “It was behind its deadlines, way over budget, and the team was pretty demoralized on it because all they heard about were all the failures.” How do you get a project like that back on track? Instead of continuing down a path that was going nowhere, she went for a reboot. “We stopped thinking about it as a huge failure and started thinking about it as a foundation. We went in and said, ‘If we’re going to do this right, how would we do it? Forget what we did yesterday. What would we do?'” In other words, the team “scrapped the whole approach.” They were using waterfall but shifted to agile instead. “We re-platformed and rebranded the whole thing, the team got reinvigorated, and we found success.” It’s a new year, but like Mitzi, maybe you’re stuck with the same old project. How do you overcome failure? During a recent PMI Symposium, we asked seven experts for advice. Here’s how they tackle the problems. Tap Internal Know-how Irene, a program manager at a healthcare organization in New York, recommends getting to know the people on the project. “Lots of times they’re under-utilized,” she says. “I find when you get to know them and you take the time to talk to them, they really have a wealth of information,” which could be used, she pointed out, to pull a project back from the brink. For example, one project she worked on was installing an editing tool for claims that get processed. It was only during the testing phase that she found out the “business owner” of the tool wasn’t the person who works on the claims database. Actual users “should have been involved in the requirements phase because they had great insight. We could have done things differently if we’d talked to them originally.” Broadcast the Urgency Mike, who works in a pharmaceutical PMO in Minnesota, said the best thing he’s ever done on a project that “required additional overtime and required all-hands-on-deck” was to fill the department fridge with Jolt Cola and Mountain Dew. “Mentally it made a difference,” he recalls. “I don’t know if people are really gung-ho about drinking twice the caffeine; but it showed the urgency and importance of the project, and that the PMO was behind the team to accomplish those activities.” Ask for Help Melissa, a portfolio manager at a major regional utility, believes in going straight to the top when things head south. “Getting your executive involved makes a huge difference,” she says. But she doesn’t go cold-calling. She was advised early in her career to “ask lots of questions” and to set up regular meetings with the business sponsor to begin with. That allows her to understand, “what’s the stuff I have free reign over and what’s the stuff [he or she] wants me to check in on.” Over time, she’s learned how to determine which events needed to be “escalated,” because they “could cause the project to stop in its tracks.” Also, this PMP tends to take possible solutions into those meetings when she can, but her approach is to be open minded: “Here are the steps we’re taking. Is there anything else you think we should be doing?” “You can’t pretend to know the answers,” she notes. “If you’re really stuck, that means you’re at the point where you need some help or you’re going to be at that point.” And sometimes there are no answers for her to bring to her sponsors, “because something side-swiped us from someplace else.” In those cases, her job is to encourage people to come together, figure out what happened and determine the risk. From there, it’s up to the executives to make the decision about what should happen next. Remind People Why the Project Matters Sometimes you need to make sure the project gets off to a good start. Suman, a PMO director in a global service provider, makes sure that the project has been represented to its participants not as a series of deadlines and tasks, but as something that’s going to serve a purpose. Many of the projects where he’s been involved do that by having the team members create a joint vision statement in order to help understand the impact it’s going to have when it’s finished. “That’s so people can relate to it, so it doesn’t remain a programming exercise,” he explains. “It’s something that is going to improve the quality of life for an individual. Those are the things that make a big difference.” To make sure the vision statement “sticks,” it’s printed on a small card and stuck up in everybody’s cubicle “as a daily reminder.” Understand Your Stakeholders Bryan, who runs the PMO for a national organization focused on affordable housing, makes sure he gets to know his stakeholders. Doing so ensures that when a project hits bumps, the PMO will understand what motivates them, what they’re “ultimately looking for,” and therefore what the best resolution would be. That kind of relationship-building doesn’t happen in meetings, he emphasizes, because those are focused on the business at hand. “Most of the time it’s walking around, stopping and saying, ‘Hey, how are you doing?'” Kill Early and Often Of course, sometimes projects need to step off the ledge. As Dave, the head of a PMO for a manufacturer in Wisconsin, suggested, when managing a wayward project, you shouldn’t wait. “Do it now. Take that project by the horns, figure out what’s wrong with it, and either get it back on track, put it on hold or kill it.” If you ignore the problems, he adds, “It’s going to continue to burn cycles.” His preferred approach is to use a steering committee to prioritize work and then “cancel projects helpfully.”   Image courtesy of Mark Fischer — CC 2.0

Ernst & Young Buys UMT Consulting

Project and portfolio management consultancy UMT has been acquired by Ernst & Young in the United States. The smaller firm, which has offices in 10 locations, was named Microsoft PPM partner of the year in 2013. Earlier this year EY formed a strategic alliance with Microsoft to work with enterprise customers in making the transition to Microsoft’s cloud and data platforms. EY has several business lines that use Microsoft technologies, including Program Performance Center, a service that does portfolio and program optimization across the enterprise, using a combination of  Microsoft Azure, SQL Server, Project Server and Power BI alongside EY’s own integrated suite of program management processes, data capture and analysis protocols. The latest deal offers several benefits to EY: Clients will be able to obtain end-to-end PPM services from a single vendor; UMT’s consulting talent will accelerate EY’s abilities to deliver those Microsoft-based solutions; and The amplified focus on Microsoft will bolster the relationship both companies have with Microsoft’s sales teams across regions. “We see the joining of UMT Consulting and EY as a win for the industry,” said Kevin Turner, chief operating officer at Microsoft. “This pairing will enhance the potential of our alliance given the new capabilities this will give EY in the Microsoft project space.” Carmine Di Sibio, EY’s global managing partner for client services, believes the new pairing will allow the expanded company to better serve the organizations it consults to. “UMT Consulting’s methods are a natural fit with EY’s existing resources, and the talent we are bringing into the organization is second to none,” he said. “With many global enterprises grappling with the challenge of getting a handle on disparate projects that are coming in both over time and over budget, this addition can enhance EY’s ability to deliver business transformation and portfolio management services by leveraging UMT Consulting’s proprietary methods.”

  • 1
  • 2
  • 5