Skip to main content

Tag: Change Management

Project Nirvana–The Secret of Mastering Your Project

I’m just going to come out with this. Here’s the secret. Ready for it? No really, ready for it?

The SECRET is that there’s NO SECRET. Sorry to disappoint. There’s just NO SECRET.

In fact, you should NEVER try to MASTER any project, EVER.

Let me repeat that.

As an Effective Project Manager (EPM), you aren’t in the business of mastering anything except helping others get to their finish line. Helping others is your product. That’s how you achieve a state of nirvana for yourself as a person.

Project Nirvana is a myth.

However, nirvana for yourself is very real. If you aren’t helping others achieve their goals, what are you doing? Please let me help you pack your bags because you’re not needed in the new world.

Related Article: Be a Mindful Project Manager

As an EPM, you don’t own the finish line. You help others get to theirs. You HELP others determine what their goals are, not yours.

Here’s why:

  • Your job as an Effective Project Manager (EPM) is to guide others; you’re the coach. If you master anything, master your ability to help others get to their finish line.
  • PROJECTS END. Don’t tie yourself to a single project or a single product for your success or failure. Projects end. You need to tie yourself to your own long-term gaze for your own success. If you are made to FEEL like your success or failure as a project manager depends on one project . . . Get out and get out NOW. Visionaries understand that success isn’t achieved overnight. It’s achieved through long-term thinking, an open mind, and sometimes a cup of coffee. Projects end, but creating value, is forever.
  • You are 100% customer service oriented. Let me explain this point. Focusing on customer service for your project team doesn’t mean you do whatever your customer wants. It means that you need to define your own customer service levels.

Think of yourself as a company. A company of one. Your company has a customer service department. What kind of customer service scores would you receive from your project stakeholders? How would your project team score you? Here are a couple points to help drive up your customer service scores:

Figure out when to use tough love customer service vs holding hands

TOUGH LOVE CUSTOMER SERVICE

  • Not all stakeholders are created equal. Some need tough love.
  • Tough love customer service is necessary when accountability is lacking
  • Examples:
  • A decision needs to have an owner
  • An entire initiative needs an owner
  • The days are gone when the ivory tower comes up with all the ideas, makes all the decisions, and then carefully trickles it down to the people. What’s wrong with this? Politics is wrong with this. It hides the problem. The ivory tower can spin which initiatives to associate itself to, clearly picking the winners and staying clear from losing projects. Don’t give executives an out to blame someone else for their vision. Here’s the truth, if you’re working towards the right vision.  There are NO LOSING PROJECTS.

HOLDING HANDS

  • I LOVE HOLDING HANDS WITH STAKEHOLDERS! I mean, who doesn’t? The OLD thinking is that holding hands is a bad thing. I’ve heard so many project managers say “Oh my holy expletive[be creative here], I can’t believe I’ve got to hold my customer’s hand on this project.” This statement is typically followed up with “I don’t have time for this!”
  • The truth is that HOLDING HANDS is AWESOME! The NEW thinking is that this is where you can help show others the way. Help them help themselves. You’ve got experience. You’ve been to the mountain. You know the general order of how to get things done in this business world and can be a sherpa to your customer. There is value in this. There’s also power for companies who harness this key EPM skill.
  • If you embrace this point, you are well on your way to real NIRVANA. I’m talking the real deal.

Go out and get you some NIRVANA!

I hope you enjoyed this post. Please share the love.

How to Increase Teamwork to Ensure Project Success

As I work with manufacturing and distribution clients from all industries such as aerospace, building products, and medical products and across a wide range of sizes from a few million to multi-billion dollar companies, I find that project management is one common thread across every client. Since growing the business and improving performance is of paramount importance to compete, new programs, process improvements, and other organizational changes continue to increase in numbers to support this expectation. Thus, project management is increasingly a strategic imperative to success.

We can be more assured we’ll achieve success with our projects if we have strong teamwork. Two minds are better than one tends to come true 99.9% of the time. What one person misses another one catches. What is one team member’s strength is another’s weakness. One person’s relationships supplement the other team members’ relationships. Thus, a team can accomplish at least 10 times what any individual can achieve. It is well worth it to figure out how to increase teamwork success. Several keys to success include:

  1. It starts at the top: As with success overall, it is most easily stimulated from the top. If the project leader and project sponsor foster teamwork, it will occur. As project leader, notice when team member’s work together to brainstorm ideas or when they help each other with tasks. If you notice and communicate the value of these, teamwork will increase.
  2. Communicate the value of teamwork: Again, solid leadership will “win” the day. Set your project up for success by communicating the importance of teamwork. Make sure you provide examples and clearly communicate the importance and how teamwork will tie to the end result and the value to the organization.
  3. Establish common metrics: One of the keys to increasing teamwork is to establish common metrics. If one member can succeed while another fails, teamwork will not occur. The team must understand that they are in “it” together. Make sure your metrics drive the behaviors you want to occur.
  4. Ask teamwork questions: While following up on the critical path and project progress, make sure to ask specific questions related to the importance of teamwork. People do not pay attention to what you pontificate about; they pay attention to what you seem genuinely interested in on a day-to-day basis. Thus, include questions that demonstrate that you value teamwork.
  5. Bring out individual strengths: One value-added way to encourage teamwork is to bring out each person’s strengths. If the team can leverage the collective strengths of its team members, there is no doubt success will follow. Search for the strengths of each member. Highlight them. Encourage people to focus on strengths and deter the parts associated with their weaknesses to teammates with strengths in that area.
  6. Communication skills: Develop your project team. Teamwork can be a learned skill. Help each person understand the best ways to communicate and collaborate to aid teamwork. Provide examples.
  7. Mentoring: As much as we’d like to think that a training class solves all ills, it is just the start. Mentoring is required for success. Dictating teamwork is like dictating to complete calculus homework without any idea of how to complete the problems. Mentoring means “living an example.” Make sure you exemplify the right behaviors. Find other exemplars to refer to as well. Give people an opportunity to test new ideas. Do not beat them up for mistakes; instead provide corrective feedback and make sure they know that you believe in them.
  8. Critical path focus: Typically the critical path is focused on cross-functional tasks as they are the ones that directly contribute to the project’s timing and success. Emphasize the importance of teamwork as it relates to cross-functional tasks. Undoubtedly, teamwork is bedrock to succeeding in a cross-functional environment. Make sure your team understands this tenet.
  9. Performance feedback: Since project metrics have been set up to track team progress, make sure that performance feedback also aligns. Again, as obvious as it sounds, the team member must receive performance feedback from their manager that aligns with the value of teamwork. They cannot succeed in getting a huge raise if they acted as a lone ranger on a project. If so, teamwork will fail. Follow up with the managers of your team members, and make sure they understand the metrics, their employee’s strengths and weaknesses as it relates to the project, etc. Make the time to ensure this feedback makes its way into their performance review.
  10. Communicate, communicate and communicate: Just as in real estate where location, location and location are the three most important attributes of a new house, communicate, communicate and communicate are the three most important attributes in achieving any desired objective. If all team members, supporters, sponsors and other related parties understand and value teamwork, it will succeed.

Related Article: Project Leadership Remains #1 Key to Success

Since executives count on projects to deliver the vast majority of improvements to their company performance, fostering teamwork can greatly increase the chances of delivering a project on-time, on-budget and on-results. Those who follow these ten strategies will succeed significantly more often than those who don’t. Why take a chance on what’s vital to business success?

Leadership Lessons: Implementing Change – Phase 3 – Understand the Status Quo

Editor’s note: We will be showcasing each phase of Peter de Jager’s methodology in weekly posts. Click here for phase 1 and 2 and check back every Tuesday to read the next phase.

Creating something new, is always an act of destruction. When implementing change you replace the old status quo known to everyone, with a mere vision of a goal in the future. Having respect for the existing Status Quo, builds respect for you.

  • How long did it take to establish?

Some status quos have been around for only a few months, others for years. The older the status quo, the more likely it will be difficult to remove. The older a status quo, the more it’s been proven as being valid. It’s easier to buy a new car, than it is to buy a new home. It’s not because of the smaller financial cost, it’s because of the larger emotional investment.

  • What investment/sacrifice did people make to achieve it?

How much have people invested in this status quo? Did they build it on their own time? Was it something that ‘cost’ them personally? The more they’ve invested in the past, the more difficult it will be to move them forward.

  • How many people subscribe to it?

Is this a corporate-wide ‘status quo’ or is it something that only a handful of people share? Is it a part of the corporate culture or just a local way of doing things? One of the measures of the size of a change is how many people will be affected by it.

  • What Values does it encompass?

If the status quo is also a part of personal values, or beliefs, then it may pose additional challenges. Example: Getting rid of the corporate Christmas turkey may be more difficult than changing the accounting system, because the turkey connects with ideas of gift giving, Christmas, bonuses and friendship. Culture is supposedly something difficult to identify, if you examine an organization in light of relationships, then culture becomes more visible. It also becomes visible of course… when you inadvertently try to change it.

  • What mythologies support it?

Each corporation re-enforces its beliefs/status quo through stories. e.g.. Nordstroms and the late night delivery of a customer’s parcel through snow reinforces the concept of a certain level of customer service. If your goal was to change customer service levels, then that particular story would have to be addressed somehow. Even if only because the staff would remember and look to that story for support of the status quo.

  • Who are the Heroes & Heroines?

Who are the people in the history of the corporation who have become major influencers, even if they are no longer around? What stories are connected to them? What were their beliefs regarding change?

© 2015 Peter de Jager – Reprinted with Permission

From the Sponsor’s Desk – A Great Project is Like Beautiful Music

We often fail to see parallels in life that can provide valuable insights and meaningful direction. Sometimes, stepping outside the box of our usual personal and professional lives can provide that Ah-Ha moment that helps set a new and successful course. 

In this case, a project manager was experiencing a number of challenges on his project. He was also a drummer in a local rock band. He and his bandmates had an upcoming gig and were excited about the progress they were making on some new songs and a new set. For the PM, the excitement over the new musical opportunity helped diffuse some of the frustration he was feeling over the project difficulties. The music was a helpful distraction. He didn’t see the parallels that would have helped solve his project problems. He was treating the two as separate and distinct activities. Luckily, lunch with a colleague helped him gain some needed perspective from his music that he was able to apply successfully to his project.

Thanks to D.A. for the details on this case.

Related Article: Nine Steps to Project Success

The Situation

This project manager was running a $3 million, fourteen-month project to launch a new financial services product. The project was well into the development phase but experiencing some significant issues that were starting to impact the schedule and budget:

  • The sponsor was vacillating over some key design features and wasn’t making the timely decisions needed to keep the project on track. The PM met with the sponsor on numerous occasions regarding the need for some firm decisions on the design matters, but the situation persisted.
  • The users assigned to the project by the organization that would administer the product going forward kept changing the user interface requirements. The PM met with the users and their manager to resolve the problem, but they insisted that the requirements were evolving as the business processes were being developed. The interfaces would have to change accordingly.
  • The project was having problems with code quality that had come to light during unit and integration testing. His developers insisted the test conditions and cases were the problem. The business unit testers claimed the code was the problem.

Frustrated with the project’s progress, the project manager invited a colleague to lunch to discuss the situation. The colleague was a consultant who specialized in application and technology architecture practices. In his former lives, he had been a software developer, database analyst, and project manager.

The Goal

The PM’s intent was to mine his colleague’s extensive experience to get some clarity on the problems he was facing on his project and perhaps arrive at a course of action that would get the project back on track. He had also volunteered to pick up the lunch tab.

The Project (Lunch)

The Project Manager and his consultant colleague arrived at their lunch destination and managed to get a quiet, out of the way table. During the initial small talk, the consultant mentioned that he had gone to a rock concert the night before. Apparently, it was an awesome, ear-splitting experience.
The PM talked about his involvement in music and the upcoming shows his band had arranged at a local pub. He talked about the two original songs they were working on, one his own, and the covers they were doing, the give and take, the trial and error that was needed and the hours of practice they went through to ensure a polished performance. He also mentioned they had dropped the bass player recently, and that had caused some friction. He was a great guy but didn’t have the talent they needed. The friction soon dissipated when they found a terrifically talented bassist to replace him.

Finally, they got around to talking about the project and the challenges the PM was having:
• A sponsor who wouldn’t or couldn’t make up his mind
• Changing requirements
• Code and test quality issues

The consultant listened and asked a few questions but otherwise let the PM have the floor. When the PM had finished describing his project challenges, the consultant paused for a moment, took a sip on his glass of draft, and then offered an interesting comment. “Delivering a great project is just like creating beautiful music. It doesn’t matter whether you’re Beethoven, the Beatles or Beyoncé. If you want to create beautiful music or a great project, you need the right ingredients and the knowledge and commitment to using them well. Take a look at your band. Who is writing the new songs?”

“I’m writing one of them. Our lead guitarist is writing the other one” replied the PM. “Why do you ask?”

The consultant explained. “When you decided to write that song, you had an idea of what you wanted to do, what sentiment you wanted to get across, the subject you wanted to cover, the tempo, a run of notes, maybe some lyrics. So, how does the final version of your song compare to what you first envisioned?”

The PM thought a moment. “It’s quite different from my first attempts. Much more lyrical. A slower tempo. The same subject, though.”

“And how did the song evolve from your first attempts to the finished product?” the consultant asked.

The PM pondered the question. “Well, I played around with the melody a bit. Fit some lyrics to it. Tweaked the melody. Changed the lyrics. When I had a rough idea of how it would fit together, I tried it out on Ron, our lead guitarist. We bashed away at it until it sounded pretty good and then introduced it to the rest of the guys. Collectively we refined it until everyone was pretty satisfied with the results.”

“Did you have conflicts over the song?” asked the consultant.

“Oh ya” replied the PM. “There was a lot of debate over the chorus lyrics. Ron and I got into some heated arguments. The other guys helped us work out the issues. The new bass player was a great mediator. Offered some terrific suggestions that got us unstuck. So where are we going with this anyway? Can we get back to my project troubles?”

The consultant went on to explain the parallels between creating that new song and running a successful project.

  • Every song needs a composer who creates the initial idea. Similarly, every project needs an initiator, a sponsor, who develops the basic vision of the desired end result.
  • A song usually needs collaborators, lyricists and musicians who help refine the initial idea into the final product. Likewise, projects need contributions from other executives, subject matter experts, technologists, business process designers, user experience experts and others to deliver a final solution.
  • A song needs a conductor who organizes the other players and their notes into a cohesive whole. Projects also need a conductor, a project manager, to plan, organize, communicate and control project progress.
  • Of course, a song needs musicians who have the skills, capabilities and availability to perform a piece on the scheduled dates. Projects also need contributors with the talents and availability to deliver the desired solution on plan.
  • A song needs to be practiced by the artists who will perform the piece. That practice often includes revisions to the lyrics, music and tempo to suit the musicians and the intended audience. Project components also need to be practiced, or tested, to ensure they fulfill their intended purpose in the hands of the people who will be using them.
  • Every song needs an audience, the final test. Likewise, projects have users who rely on a delivered capability to achieve the desired result.

The consultant offered the following analysis: “It seems the problems you’re encountering with your sponsor are directly related to the lack of collaborators he has available to help him sort out the issues. You’re the conductor, the organizer. Instead of leaving him to his own devices, bring the sponsor and the collaborators together to resolve the design issues that are causing the project grief. The requirements changes you’re experiencing seem to be the result of your staff working independently rather than collectively. Again, you’re the conductor. Don’t keep them at arm’s length. Bring them together. Have them share responsibility for delivering the process designs and the resulting interfaces. Finally, the quality issues sound to me like a skill problem. Find out if your software developers have the necessary language, business, and technical skills. Find out if the testers have the skills and tools to develop and administer the test plan, develop robust test cases and interpret the results.”

The PM thanked the consultant for his help. With new insights on the problems and an action plan of sorts, the PM returned to his office with a new bounce in his step.

The Results

The PM met with the sponsor about the product design issues and got his agreement to involve the marketing and sales executives in a design workshop run by an independent facilitator. The session was a terrific success. Problem #1 solved.

The PM then turned his attention to the requirements changes. He worked with the software development and product administration managers to bring their teams together and collaborate on the process and interface designs. The software developers prototyped the interfaces but held off on the final code until they signed off jointly on each design. That effort almost eliminated the cycle of continuous changes and the need for rework. Problem #2 solved.

The PM brought the software development manager and the testing manager together to discuss the consultant’s suggestion that a skill gap was behind the test problems. The developers were experienced and highly rated. The testers were new staff the manager had hired recently. He acknowledged that they probably didn’t have the business or testing expertise to do the job competently and agreed to assign and experience test lead to oversee progress. Problem #3 solved.

The project was delivered well under budget and three months ahead of plan. A great project really is just like beautiful music!

How a Great Leader Delivered

The PM’s first good move was seeking input from his colleague. That’s a great move on any project – having an exchange of ideas with someone who can offer unfiltered insights on any issues or successes, you’re encountering. A Project Mentor, so to speak. Finally, he took advantage of the insights offered by his colleague and leveraged the multiplying power of collaboration to see his project delivered successfully.

So, if you find yourself in a similar situation, think about all those outside interests you share, including music, and how they may be able to help you get the job done. Also, be sure to put these points on your checklist of things to do in future endeavors so you too can be a Great Leader. And remember, use Project Pre-Check’s three building blocks covering stakeholder, the decision management process and Decision Framework best practices right up front, so you don’t overlook these key success factors.

Finally, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, don’t be shy! Send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights. Thanks

Speaker Spotlight: Can You Collaborate?

In this article, Robin Hornby presents his case for a new way of managing contracted projects and introduces the concept of a collaborative lifecycle.
Hear more about these ideas at ProjectWorld Vancouver Sept 14-17, 2015.

There are many behavioural models out there (the Keirsey Four Temperaments, Myers-Briggs, Social Style Profile, Lumina Spark, and Marston DISC® model among others), but I am not aware of any that explicitly sort us on the axis of Collaborate-Compete. I suspect there is a bit of collaborate and compete in all project managers though most will fall on one side or the other. Recently I have been wondering what the implications are for PMs in professional services and their clients. How does the Collaborate-Compete preference reflect the organizational approach to contracted projects? Is there a correlation with project efficiency and positive outcomes?

The Marketplace

The project marketplace seems like the antithesis of collaboration. Commercial free-for-all, regulatory and procurement policy constraints, zero-sum contracting terms, arm’s length stakeholders, hidden communication channels, project delivery under commercial pressures, as well as the usual quota of technical and project management issues creates a complex project environment. It’s certainly competitive but can be time wasting and frustrating. Surely there must be a better way, and that ‘better way’ increases in importance as the boom in project outsourcing over the past 20 years continues. 

Delivery Silos

Strangely, many clients seem to regard procurement as coming to an end when the vendor has been selected and contracted, rather than when the product is delivered and accepted. Perhaps this complements the concept of risk transference associated with fixed-price contracts. Another cause might be the emergence of two (or more) silos of activity – client team(s) and vendor teams(s) – whose management interactions are limited and formal, with occasionally an unhealthy dependence on the vendor’s expertise for anything but the basics. A vendor can unwittingly encourage this, accepting a client’s lack of rigour on status reporting and resource allocation. (Unbelievably, I have had clients tell me in no uncertain terms that they don’t want to waste their time and money on status meetings.) On the other side of the fence, I have heard vendor PMs wish that the client would sign off the requirements so we could get back to the office and build the product! None of this sounds like collaboration. Unfortunately, there is no accepted framework that supports a collaborative approach through all the phases of project proposal and delivery, and it is my vision to address that.

The Case for Methodology

I believe that without formalization, just like standard project management, attempts to improve the record of project contracting will be sporadic, temporary, and based on heroic measures by rare combinations of exceptional people. The proposed formalization is Total Collaborative Procurement (TCP). Using the qualifier ‘Total’ reminds us that successful procurement is more than selecting a qualified vendor. We must include the entire delivery cycle and forget about the idea that all risk and problems are delegated to the vendor. Projects are always a joint endeavour.

What might be the requirements for such a methodology? I have identified twelve; foremost of these are a business focus and an executive role over PM and the work itself. It must be low in documentation demands and adopt a checklist approach. It must assume a delegation of business decision-making to PMs. It cannot be detailed and process-driven. I am suggesting a structure of collaborative practices within a commonly accepted joint business lifecycle.

Shown in the diagram below is a three level architecture that fits these requirements. It offers a starting point for TCP development. The work level emphasizes the use of a project lifecycle (it can be any – Waterfall or Agile), but is essential for the key practice of Lifecycle Mapping. The PM level is based on the functions (not processes) of project management – Plan, Organize, Control, and Lead (POCL). The new business level is an amalgam of the existing buyer procurement lifecycle (ref. PMBOK®), and the best-practice vendor lifecycle (ref. Projects for Profit). This comprises five as yet unnamed phases, home to a probable total of 15-20 practices.

 rhornbyarticle1

Note that the diagram illustrates how the TCP includes delivery in Phase 4 by acting as a ‘wrapper’ for the execution of the contract agreed in Phase 3. In the example shown, the contract is for a big bang project including all project phases. An alternative rolling wave approach would entail two or more cycles of the TCP.

Benefits of the Framework

Senior client and vendor managers concerned with successful procurement, delivery, and closure will now have a defined and consistent basis upon which to conduct their business and shared interest in the project. This contributes to optimization of contract design, more open, efficient conduct of the project, and builds a foundation for the development of trust between the parties.

The contemplation of PM as a four-function model fits extremely well into the demands of the commercial world. No one disputes the need for knowledge of standard processes as found in the PMBOK®, but POCL provides a highly relevant skills and training model as well as permitting clarity of integration of PM with the project lifecycle. Lifecycle Mapping, as I call this technique, is the first of six collaborative practices I will discuss in the second part of this article, as well as some of the challenges of implementation.

Feedback

There is a methods vacuum in the commercial arena, and unless this initiative, or something similar, is taken into development, I can’t see any reason for commercial projects to improve either in efficiency, in outcomes for stakeholders, or in the equanimity of the project managers. What do you think? Are the ideas presented feasible? I need feedback and would welcome your comments below, or by email to [email protected], or by question and comment at the ProjectWorld Vancouver Conference.

References

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK® guide) – Fifth edition. Newtown Square, PA: Author.
Hornby, Robin (2013).

Projects for Profit: An insider’s guide to delivering projects and getting paid. Calgary, Canada: Tempest Management Inc.