Archive for the ‘Project Management Articles’ Category
Projects vs operational work – How do companies organise to be ‘best’ at both?
Read it on the blog is a project and engineering management discussion blog. A kind of ‘Carrie Bradshaw’ view of the engineering blogging world, only without the shoe fetish!
The aim of this, my second blog, is to open a debate on what is the most appropriate organisational design for companies that are required to deliver high value operational work alongside high value investment programmes. The blog assumes a basic understanding of functional, projectized and matrix organisations. For readers who wish to understand more about these definitions an excellent overview can be found at wikipedia.
I welcome reader engagement and feedback of your views and personal experiences regarding how organisations structure themselves to deliver the different capabilities of ongoing operations and project delivery. If you wish to comment please click the title of this blog and enter your comments in the box at the foot of the page.
Some options that I have encountered include:
1. Create separate functions for operational work and programme/project delivery, alongside typical support functions such as Finance, HR, Legal, IT etc.
2. Create a single function that delivers both operational work and programme/project delivery, alongside typical support functions.
3. Establish separate business divisions for operational work and programme/project delivery, each division containing all the necessary resources required to deliver its objectives.
4. Establish a matrix organisation, containing functions that are tightly defined centres of excellence alongside a programme/project delivery function that is accountable for defining the ‘what’ (programme scope), ‘when’ (programme schedule) and ‘how much’ (financial plan) by jointly managing resources within the the other functions whose leaders are primarily accountable for the ‘how well’ (quality).
So now for the ‘Carrie Bradshaw’ bit
Option 1 may be ideal, providing the demand for operational work, is closely matched to the direct labour resource capacity such that the organisation can meet its required levels of service whilst achieving high levels of resource utilisation. In other words there are no stranded resources or ‘fire departments’. But how often does this situation apply in reality? Possibly in the case of organisations that manage continuous processes, but not so for utilities whose assets are exposed to the effects of weather and other external factors.
Option 2, in my experience, is adopted to address the issue raised in option 1 such that, by combining operations and investment delivery, an opportunity for utilising operational resources on project work during periods of low operational activity is provided. But what does this mean for project delivery ? What happens to projects when the organisation experiences high levels of operational activity? How can programme/project managers produce accurate programme schedules when they don’t know what resources they have at their disposal ? Does programme/project delivery become the poor relation to operational work?
Option 3, is ideal for organisations whose operational activities and investment delivery activities are dissimilar such as water and waste water utilities and where the demand for work is extremely large. Each division being essentially a standalone organisation.
Could option 4 be a solution to the issues experienced by option 2? Establishing a professional programme & project management department within the investment delivery function. A function whose accountability is to deliver the organisation’s investment programmes utilising a common programme management methodology based on best practice and the needs of the organisation. Could this be achieved whilst maintaining a close relationship with the other functions in the organisation through joint management of resources? Is it possible to be ‘best’ at operational work AND project delivery, or does one always succeed at the expense of the other?
I welcome all views, especially those relating to utility industries, please comment.
Project Management Blog – Connecting Developers, Building Worlds
Do You Recognize Progress?
I recently read an interesting article in the Working Knowledge newsletter put out by the Harvard Business School written by Carmen Nobel. "All good managers understand the importance of making sure that every member of a team feels personally motivated and necessary though the workday, lest their work should stagnate and suffer," she says. "But what’s the key to igniting creativity, joy, trust, and productivity among your employees? According to recent research, the single most important factor is simply a sense of making progress on meaningful work. But creating an environment that fosters progress takes some careful effort."
I’m a big believer that small and incremental actions can lead to exponential improvements in almost any situation over time. Nobel cites a new book by Teresa M. Amabile and Steven J. Kramer that I’ve just added to my "need to read" list: The Progress Principle: Using Small Wins to Ignite Joy, Engagement, and Creativity at Work.
The authors collected stories from 238 white-collar employees from seven different companies within a variety of industries. They had each worker fill out a diary during the day to answer a pretty open-ended question: "Briefly describe one event from today that stands out in your mind."
Have you ever experienced a day where you were head down, working like crazy but at the end of the day you didn’t feel like you got anything done—you didn’t make progress on anything? I know I have those days. According to the authors, this is a big deal and a real motivation killer (my words not theirs). "We found that of all the events that characterized the best inner work life days, by far the most prominent was making progress," they say. "And of all the events that characterized the worst days, by far the most prominent was setbacks—feeling like you’ve lost ground on a project. As a pair, progress and setbacks are the main differentiators of the best and worst days."
The good news is that although it takes some thought, it’s the small events that have a major impact on work life. "We found that 28 percent of small events of all kinds had a major impact on inner work life," write Amabile and Kramer. "This is good news! Big breakthroughs at work are really rare. But small wins are something people can experience pretty regularly if the work is chunked down to manageable pieces. This suggests that you really have to sweat the small stuff."
I think there are a couple of really important factors that will help project teams experience those small wins at regular intervals. I think we just need to change how we interact with the team and how the team interacts with the process:
- Make the project management process more social: Give team members visibility into what their colleagues are doing, encourage them to interact and make comments regarding the work. If social media has taught us nothing else, it has taught us that people will interact and make comments about what their friends are doing. If we can foster an environment at work that encourages that type of communication regarding tasks, issues and projects (work) individual team members will feel a sense of recognition and accomplishment regarding their work as colleagues comment and "like" what they’re doing.
- Give the team some autonomy: I’m not advocating an anarchistic project management approach, but engage the team early in the planning process. Give them a voice in time-lines and deliverables. This approach works pretty well with SCRUM teams. Shouldn’t we allow those closest to the work some decision-making authority in how things are done and who they are done with?
- Recognize accomplishments: Sometimes the only time the team hears from the project manager is when things fall behind schedule or the project is in trouble. If this is the case in your organization, nobody wants to hear from the PM. Of course that doesn’t mean that recognition should consist of insincere platitudes. A simple acknowledgment of good work is often enough to provide team members with a sense of accomplishment.
- Make sure everyone knows what the goals are and then get out of the way: "People need to know what goal they’re trying to reach, but they have to have autonomy in order to get there," Amabile says. It’s a delicate balance. You do want to make sure that people understand what their mission is, but you don’t want to micromanage them. If you do, their creative thinking shuts down, and you lose the value of their unique talents, expertise, and perspectives."
This isn’t rocket science. If anything, it probably sounds too simple to be of any value. However, over the course of my career I’ve seen these three simple techniques work. Through small means great things are often accomplished.
What are some of the "small" things you do on your project team that reap "big" results?
Failure or Success?
The Russian writer and physician Anton Pavlovich Chekhov once said, "One must be a god to be able to tell successes from failures without making a mistake."
Where projects are concerned that is often the case. Recently, a colleague and I were discussing the Standish Group’s Chaos report and debating whether or not their definition of project failure is really accurate. Although I agree that if a project fails to deliver the anticipated value, takes longer than expected or costs more than is budgeted I think it’s safe to say that it wasn’t a success—but does that also make it a failure?
Sometimes.
Yeah, I’m weaseling a little bit here. However there have been some pretty high-profile failures that turned out to be anything but failures. Take Columbus for instance, he was looking for a quick route to India and found the New World. Was he successful at finding India by going West, no. Was it a failure?
Sometimes I think projects are doomed to meet the Standish Group’s definition of failure from the start. Stakeholders and sponsors aren’t clear with their expectations, project leaders are handicapped with unrealistic time-lines and project teams are woefully understaffed. When these conditions exist, is it any wonder that a project team struggles to hit a moving target with a broken bow and arrow?
With that in mind, let me make a couple of suggestions that might help keep your projects out of the "failed" category (at least according to the Standish Group’s definition):
- Define Success: This sounds pretty simple, maybe even too simple. Nonetheless, how many projects have you been a part of that didn’t have a clear definition of what success was before it started? Imagine shooting a basketball at a hoop that randomly moved during the game. It’s tough for project teams to hit a moving target.
- If the Scope Changes, So Should the Definition of Success: I’m not a big fan of willy-nilly changes in the scope of a project, but if there are compelling reasons (other than the team is trying to reduce requirements to meet a deadline—which would indicate "failure" in my opinion) to change the scope or requirements, it’s not accurate to call the project a failure if it costs more or takes longer to finish.
- Be Honest and Engage the Team in Resource Estimates: Arbitrary deadlines just don’t make sense and should be avoided at all costs. One of the things I like about the SCRUM methodology is the Sprint Planning Meeting. The team estimates resource requirements and takes ownership of their estimates. For project managers, this type of approach makes sense to me. Those closest to the work understand it the best and should be involved in making decisions about the time-line. What’s more, giving the boss the time-line he or she wants because he or she wants it isn’t a good idea if it’s not realistic—and sets the team up for failure.
- Build the Right Team: Just because someone is available doesn’t mean that they are the person for the team. I know that many project managers don’t have the luxury of picking their team, but can exert influence over who is or isn’t part of the group.
Of course there is no silver bullet to avoiding the "failure" category. I’ve participated in discussions that suggest (for a number of reasons) that the Chaos information is inaccurate. Even if the actually results are 50 percent better than reported, it’s still too many failures. As project leaders, our job is to help get things done—successfully. That being said, what do you do to ensure project success?
Strategic Project Management
Does It Matter If It’s Not Your Career?
Over the last several months (if not the last year) I’ve expressed my concerns about the potential for a mass talent migration from organizations who have compelled the workforce to work and produce more for less. Anecdotally, I know of a number of people who are very frustrated at the hamster wheel the feel they are on. They complain that every day there is another crisis that requires them to work extra hours and feel extra stress. Although I agree (and support the notion) that there are times when it’s important to put in some extra effort, when crunch time becomes all the time—I think there is something wrong.
In an article published on the Grapevine, Owen Morgan asks, "So why are so many employees currently thinking about changing employers—and at a time of such economic uncertainty?"
I don’t know if you are seeing this in your organization or among the members of your project teams, but I predict that this could become a pretty big problem for many organizations who depend on their people to create and innovate. Which is why I ask the question, "Does it really matter if it’s not your career?"
I think it does.
I work with a colleague who is a very talented and capable manager. One night last week as we were getting ready to leave the office, he commented that he felt like part of his responsibility as a leader was to help advance the career of those who worked on his team. Although I have never articulated it that way, I have to agree. In fact, some of the accomplishments I’m most proud of involve helping individuals on my team advance and succeed in their careers.
"Development is the key word here—while many employees will claim that another role offers greater rewards," writes Morgan. "In many cases these are unlikely to be solely of a financial nature. It’s well known that people move roles for a variety of reasons, but the search for new experiences and challenges is often foremost among them—doubly so for those who are driven, innovate and unprepared to accept the status-quo—just the sort of people that organizations cannot afford to lose and who will be able to help their employer through the challenging times that lie ahead."
I’m convinced that people are less motivated by money than we might think. However, that doesn’t mean that we can get away with poor pay and poor benefits. What it does mean is that if you’re not the New York Yankees, you can still build a championship baseball team (without buying it).
In other words, according to Morgan, "Most forward-thinking organizations have identified their talent and even though some development opportunities are likely to have fallen along the wayside, effective and open conversations between line managers and their teams, articulating the importance of an individual to the future success of the organization can work wonders. Truly effective managers rise to the challenge here, and at the same time as ensuring that the team is deployed to achieve the short and medium-term organizational objectives that are set, they never lose sight of the longer term and how their individual team members might play a part in it."
Unfortunately, this type of behavior seems to the be the exception rather than the rule. Do the members of your project team know that you value what they do and that their contributions to the team are important to the success of your organization? If they don’t, it might be time to do something about it.
In a nutshell, Morgan sums it up this way, "So telling people they have a career with their current employer and not just a job can reduce the instances of those looking to leave."
This doesn’t mean that I’m advocating that we tell our team members that we expect them to treat what they do as more than a job. That will happen naturally when we treat them as something more than mindless employees compelled to do mindless tasks.
Does it matter if it’s not your career? It absolutely does.
Does Anybody Still Use the Pony Express?
From April 3, 1860 to October of 1861 the Pony Express carried mail from St. Joseph, Missouri to Sacramento, California. Before the telegraph, the Pony Express was the most direct means to send a message to points west. During the 18 months the the Pony Express operated, it reduced the time it took for mail to reach California from weeks or months to about ten days. It was state of the art for its day. However, I don’t think anyone uses the Pony Express anymore.
Over the Labor Day weekend, I spent a little time on the bike and one of my rides crossed the old Pony Express route. It is a pretty lonely road now, I can only imagine what it must have been like in 1861. I also thought about how communication technology has developed since the days of mounted couriers racing across the desert.
Needless to say, email, text messaging, and instant messaging (and don’t forget telecommunications) have changed the way we communicate with each other. Although I didn’t check, I’m sure when I was out on the old Pony Express route, I could have taken my cell phone out of my pocket and called home—what a difference 140 some odd years makes.
The big question for us now is, "What’s the best way to communicate and collaborate with our project teams?"
I wish I had the magic bullet answer.
If you’re like me, email is a very big part of your day. I probably spend about as much time in email as I do any other application on my computer. I also have a text messenger up all the time and my desk phone and cell phone are right next to my computer—not to mention the opportunity to walk over to the next desk and have a conversation. Needless to say, I am very connected (there are also a number of people I communicate with regularly through my project management software, Facebook, Google+ and Twitter). I have found that depending upon the type of communication, what I’m communicating about and who I’m communicating with, I tend to choose the most appropriate method for sending and receiving messages.
As project leaders, we have a lot of communication tools at our fingertips (we also have teams spread around the world). Choosing the right communication and collaboration methods to help our project teams get work done is critical to project success. How do you determine the best way to share information and collaborate with your team?
Tribal Knowledge
I spent the last few days in the Uintah Mountains fishing and camping with my family. As we sat around the campfire each night, telling stories about each other, I couldn’t help but think about the "tribal knowledge" our family likes to share at times like these with in-laws and other family guests.
Now that I’m back and in front of the computer for the first time in five or six days, I can’t help but think about the tribal knowledge that exists within our project teams and the organizations we work with. Although my daughter-in-law might find the stories about her husband’s childhood amusing, the tribal knowledge that impacts our project teams is more than amusing, it’s critical for a team to successfully work well together.
I was very fortunate when I entered the workforce that an older (and more experienced) colleague took me under his wing and shared with me the unspoken order of things within our organization. I’ll admit that some of them were pretty obvious, but there were others that were vital to helping me keep my foot out of my mouth. His serendipitous mentor-ship and the things he taught me have helped my career many times over the years.
What is the unspoken order of things within your organization? Is there any kind of established vehicle for sharing that information with those new to you organization, or do you leave it all up to chance?
Here are a few suggestions for sharing tribal knowledge that might help new members of your project teams get up to speed quickly. Of course, these are just suggestions, please feel free to share any successful approaches you might have.
- Meet together regularly as a team to share stories. This could be part of a quarterly planning meeting or other team get-together. Stories are a great vehicle for learning. And, sharing stories about team successes and failures could be a great way to share the "unspoken order of things" to your team.
- Assign a more experienced mentor to a younger (or newer) team member. There’s a reason that the trades are so successful with an apprenticeship program. It just makes sense to me that a more experienced colleague take a less experienced team member under his or her wing. This isn’t necessarily to make sure that they know how to do their job (we should be able to assume that), but someone to help navigate the nuances of working within the organization is a good idea.
- Spend one-on-one time with team members on a regular basis. Once a month or once a quarter it’s a good idea to sit down with team members for a one-on-one conversation about goals and objectives along with individual and team performance. This is also a great time to share tribal information.
Regardless of how you choose to share tribal information, I look at it as more of an ongoing process than something you eventually finish. If you are doing something to successfully share this type of information within your organization, what are you doing? Do you think it helps your project teams?
Strategic Project Management
3 Steps to Building Your Own Innovation Machine (Part 1)
Recently, I read an interesting book by Peter Sims, “Little Bets,” which brings up a really important question: can failure, in fact, take us further than success? The answer is: yes, if we know how to deal with it. While interviewing the executives at Amazon, General Motors and Google, as well as successful musicians, architects and comedians, Sims discovered one thing they had in common. All of them used the same approach of relentlessly “making little bets” to test their new ideas, even if they were not sure about their success. Most of these bets ended up as failures, but five or six out of 100 turned out to be the breakthroughs. According to Sims, in most cases, there’s no mysterious genius behind the great achievement, but perseverance and the willingness to take small risks.
In this series of posts, I’ll analyze how failures nurture success and describe how learning through failures can help you develop your business into a real innovation machine. Through hardship to the stars!
Low-cost experimentation
The idea of “successful failure” is familiar to many successful software entrepreneurs. For instance, Randy Komisar names “the culture of constructive failure” as the main reason that Silicon Valley became the world’s innovation center.
In his “Getting to plan B” framework, Komisar suggests including in the business plan the ability to quickly adjust it. All plans have assumptions, and Komisar’s idea is to focus on the most risky assumptions first and devise your work in a way to test your risky hypothesis in the market as soon as physically possible. Businesses can hardly afford big failures financially, so the key is finding a way to minimize the cost of experimentation.
Getting feedback as fast as possible can save you a lot of time and money you could otherwise lose by going in the wrong direction. That sounds obvious, so obvious that you might be tricked into thinking that you are already doing your best job there. Sometimes it’s the case, but oftentimes some thinking out of the box can help you save a lot of effort and money. For example, in the software business, a traditional approach is to develop the software and then try to sell it. An approach in the spirit of Komisar’s ideas would be to create a quick prototype, a mock demo, or a simple “slideware” and sell a contract with an advance delivery date. That’s, of course, if your biggest risk is market adoption. If you can’t sell it because nobody needs it, well, you’ve just saved a lot of money on developing software that nobody needs.
Some people are defensive and want to buy more time to tweak their solutions before presenting those solutions to the real world. This big bet works for a selected few visionaries, and the media is always quick to highlight those stories. But the truth of the world (at least in the eyes of Peters Sims, Randy Komisar and yours sincerely) is that in most cases, you’ll get much further with small bets, fast feedback and applying your boldness to facing a failure, rather than to doubling the failing bets.
To be continued…
Project Management 2.0
Teamwork and Rock Crawling
I don’t know how many of you are familiar with the term "rock crawling" or have actually had the experience of spending time behind the wheel of a Jeep or other four-wheel drive vehicle and picked you way up a boulder-strewn stream-bed or other similar trail. However, if you live near the mountains like I do, it’s one of the pleasures of owning a Jeep.
Yesterday, my colleagues and I had the opportunity to take some Razr 4x4s out into the mountains for a working? off-site to cap off a successful end of the second quarter. There were a couple members of the team who had done this kind of thing before, but there were others who had never been behind the wheel of a four-wheel drive off-road vehicle.
I have to admit that I really enjoyed bombing down the fire-roads with my foot to the floor—drifting around the corners throwing up dust and grinning from ear to ear. However, the highlight of the day for me was watching one of my colleagues who had never done anything like this before pick his way up a very technical section of trail. Our boss (who does this all the time and was very familiar with the trail we were on) talked him through almost every boulder and was encouraging every step of the way. He did a great job climbing the trail—which wasn’t diminished at all by the "mentoring" he received on the way up.
I think project teams should work the same way. I think teamwork includes more experienced team members helping less experienced team members pick through the obstacles that often tend to crop up in the middle of a project. And like my rock crawling colleague, sharing "beta" about the trail never diminishes the achievement of project success—I think it sweetens it.
Do you encourage your project teams to work this way? Please share some of your successes with us.
As Clear as Mud?
When I was in High School, I had a trigonometry teacher who was obviously a brilliant guy, but couldn’t explain anything he was talking about so we (I don’t think it was just me) could understand it. If I couldn’t figure it out by reading the textbook, I wasn’t going to understand it by listening to his lecture either. I would often leave his class feeling like everything was "clear as mud".
I’ve been part of project teams where I felt the same (and I don’t think I’m alone on this either). With that in mind, is there something project leaders should be doing to make sure that tasks, assignments and project communication is clear and understandable? Here are a few suggestions:
- Use the "My Mother" Rule: When I’m writing any project communication, I often think of my Mom. She’s a pretty smart lady and I figure if she can understand what I’m talking about, most likely the reader will understand it too. So, when you’re writing a description of a task or other communication, ask yourself, "Would Ty’s mom understand this?" If not, try again.
- Don’t Assume Everyone Knows What You Are Talking About: Sometimes it easy to make assumptions about the level of understanding that exists among the team. Just because you "get it" doesn’t mean that everyone on the team is going to be able to wrap their head around what you’re trying to say without the proper context. For example, if your only description of a task is: Update Patch for Next Release, it would be unreasonable to assume that your reader will understand what you are requesting. Take a little extra time to make sure the team has everything they need to know to completely understand what you’re asking of them (and remember #1…would my Mom get it?). I have never experienced a time when a colleague has been frustrated at knowing exactly what I was expecting, but I have frustrated people when they didn’t know what I was talking about.
- Don’t Rely Exclusively on Email or Other Electronic Communication Methods: Sometimes, it just makes sense to have an actual conversation with people. Like many of you, I have come to rely on electronic communication to share information, collaborate and respond to questions. Most of the time I think it works just fine. However, there are times when a conversation is in order. Make sure to spend face-time with the team to answer questions or help resolve issues.
- Listen to My Grandma: She always used to say, "An ounce of prevention is worth a pound of cure." Before you complete your project plan and distribute all the tasks to the team, take a few minutes and visit all those who will have assignments and give them a little advanced warning that they are going to see a number of new tasks show up on their list of things to do. It’s polite. It gives you an opportunity to provide context. And, it will always be appreciated. This is particularly true of matrix-ed organizations where the project team could be dispersed throughout the organization. If the team is spread around the world and a face-to-face conversation is problematic, I think an email or a phone call with the "heads-up" information is appropriate.
Successful projects require more than a "clear as mud" understanding of what’s expected. Team members need context to perform at their best and engage in their work. And yes, for the most part, I have always tried to listen to my Mom and my Grandma.
Strategic Project Management
Creative Economy, Virtual Collaboration and Social Media: Insights from PMI VP
Today, I'd like to share a very interesting conversation that I recently had with Brian Weiss, VP of Practitioner Markets at PMI. Working for PMI since 2007, Brian brings more than 18 years of his product management, marketing and consulting experience to this global organization. Together with his team, Brian is focused on the ongoing engagement of PMI members, certification holders and volunteers, and leads a number of PMI's fundamental programs. As a person who constantly interacts with a community of more than 500,000 people who are somewhat involved into project management, Brian always keeps abreast of the latest trends in the field. Check out the podcast to hear Brian's insights into such prominent topics as the expansion of virtual collaboration, the rise of social media, the challenges and opportunities of project management in a creative economy, and more. If you prefer eye over ear, you also can read the transcript of the interview below.
Brian, it's a pleasure to have you on this podcast! First of all, could you please tell us a couple of words about your career in PMI?
I've just celebrated my 4th anniversary with PMI. Previously, as VP for Product Management, I was responsible for various products and services we produced for practitioners and organizations looking to embrace project management. Earlier this year, we reorganized around our market focus, and now I serve as the VP of Practitioner Markets. I'm focused on the individuals, whether be it one of 20 million people who are somehow involved in project management (those who are leading or directing teams, as well as team members), 450,000 people credentialed by PMI, 350,000 PMI members, members of chapters, volunteer leaders, and more.
I know that a few weeks ago PMI held its Global Congress in Dublin, and it was a big success. Can you give a short summary of the most popular topics and project management trends that were discussed at the event?
We had almost a thousand attendants who came to share their knowledge and experience, as well as professional speakers. There were all the things you could imagine at a world-class project management conference! The content of the program followed the trends going on in the field. For instance, we're now launching a new course on agile. This was the primary focus of one of the tracks.
An interesting thing – we picked social media as a keynote. Among the thousands of individuals in 180+ countries that are part of the PMI family, not everyone is necessarily working, sitting right next to you and getting information from traditional sources. So social media as a keynote topic was a strong theme at the congress.
PMI is a global organization, so you're very well aware of the recent expansion of virtual collaboration. Do you see it as a challenge or an opportunity for project managers? Among the practitioners who turn to PMI, how many deal with virtual teams on a regular basis?
I'm not sure we have an exact number of stakeholders dealing with virtual teams. But seeing that they work for the largest and most influential companies, down to startups from 180+ countries, you can imagine that in some way or another, a large proportion of them is dealing with a virtual work and collaborating with people who are not co-located with them. It's the same exact environment that we're working in.
There are a lot of advantages organizations are reaping from working with a virtual or dispersed workforce. Some people typically point to such tangible ones as cost savings. I can set up my operation where the cost of labor is less. But most organizations have migrated beyond that, and they're looking at productivity and competitive advantages they can get from what I'd call a “follow the sun” workforce. When employees in one part of the world finish their workday, in another one they're only starting it, so work doesn't stop. On one level, you can produce more. As you're producing things more quickly, we call it schedule compression. From the point of competitive advantage, it's speed to market, i.e., you can get to the market quicker than your competitor.
Working with virtual teams also allows organizations to take advantage of products and services they create in one environment and then localize them. If you take a look at consumer goods manufacturers, they try to make them work in different locations. It's not about changing the labels or making sure the colors are right. It's about understanding the tastes, culture, laws and regulations of the new market. They need local teams.
Here's the main reason that I see behind dispersed teams: I've never been to any location on the planet that has all the smart, creative and talented people in one spot. To tap into global talents, companies need individuals who can help tie it all together. Project managers come to the forefront because they lead and direct dispersed teams in this complex environment.
This is a great comment, and I absolutely agree with you. As a professional with extensive experience in product management and marketing, you are part of growing information and creative industries, where the profile of the worker and the project is different from the industrial economy. In your opinion, which project management practices are the most and the least helpful in that environment? How should project managers adjust their behavior, tools and processes?
Recently, PMI completed its multi-year “Value of Project Management” research that produced 60-70 case studies on how different organizations can get ROI out of project management. The primary thing we found in the research is that there is no one way to do it. Project management needs to fit your organization's culture, its DNA, the way you do work, your maturity level, etc. To give companies the basis to figure out the way to do it, sort of a framework – that's where our standards come into play. Produced by global experts, they provide common practices for individuals that they can evaluate and figure out how to adapt the practices to their own company.
This becomes even more critical as we move from an industrialized world, where there was a very systematic way of work, to the type of environment you're talking about, where work can be done anywhere at any time. People need to tap into our standards and flexibly adapt the common practices to their environment.
Another critical thing in this type of environment – while there is no one way, if you figure out your way and standardize your process of work, good things happen to you. Our research shows that organizations which achieved that alleviate themselves from many typical problems of our profession.
Now let's get back to another interesting trend we started our conversation with – the social media in the consumer and business world. What are your thoughts on the recent rise of the “social” as in “social networks,” “social media,” “enterprise social software” and “social project management”?
I think it's great that our industry is embracing this powerful trend. It's a tool that enables individuals to be more informed. Our profession has the exact same challenges as any other profession has with regard to social media; “instant expert” is what I call it. If you can have a site, blog or any other ability to communicate with the masses, people tend to put more credibility and relevance into that than they previously did with traditional sources of information. It's changed our paradigm for where we turn to get insights into information. Yes, there's a risk with that, but with every risk comes an opportunity: it opens a door for lots more people to collaborate and generate knowledge. All the smart people don't live in one location. As I've already said, they are spread around the word. They get a tool for collaborating and sharing information like never before. It's a good thing as long as we look at it wisely, understand our sources and place the right sort of validation and credibility upon them.
A great point! Recently, Gartner released a research note where, for the first time, it analyzed collaboration as an essential component of project portfolio management. How big do you think the input of collaboration is for the overall success of a project?
You can never ignore organizational context. In my job, I'm responsible for the largest community of project management practitioners, and according to their feedback, collaboration and networking is where they get the most value of PMI. I'm a strong proponent of allowing individuals to gather and network, whether virtually or in person.
Organizations have different styles. Some are asking their employees to be more collaborative, and some are more directive. Different cultures obviously have different perspectives. We can't ignore that. But, in my role, I come with a very strong emphasis on networking and collaboration between individuals. Again, I keep going back to my point on global workforce. When organizations really want to tap into the best talents, they're not going to do it in one location. When individuals want to gain knowledge and insights on this, they can refer to PMI standards as a starting point. Then they need to interact in order to figure out the best way to work in the context of their environment.
Brian, this has been a very insightful conversation. Before we wrap it up, I'd like to ask you for advice that you would give to the listeners of the podcast, to project managers who are still looking for tools and techniques to make their work more efficient?
The advice that I would give is based on what we hear from our 600,000 global practitioners. The No. 1 thing is getting connected to an organization like PMI that gives them access to knowledge resources and networking opportunities. Within our environment, you get the right references to templates and tools when you're interacting with people. With the support that PMI gives, you'll find a myriad of tools and techniques that were already tested by other people that you can learn from. Also, you can give your feedback and let other people know about your experience.
Thank you for the interesting updates on project management trends and the great advice you shared, Brian! Our profession is growing and penetrating more industries and more verticals within companies. I wish you the best of luck in growing the PMI community even bigger.
Project Management 2.0



