I have a recurring issue with Google Maps that I'd like to get everyone's take on. Either I don't know how to use the service properly or there is a missing feature I'd like to see Google fix.

When I do a search in Google Maps, like "915 Broadway, NYC" (which is the address of Union Square Ventures), I get a result like this:

If you do that search, you'll see that the URL is still http://maps.google.com/. The web app does not return a new URL for that search.

You can click on the "link" field on the upper right of the page and get a popup of a long url. In the case of the "915 Broadway, NYC" search, that URL looks like this:

http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=915+Broadway,+New+York,+New+York+10010&sll=40.737143,-74.007627&sspn=0.007625,0.018389&ie=UTF8&hq=&hnear=915+Broadway,+New+York,+10010&ll=40.740933,-73.990002&spn=0.007625,0.018389&z=16

Not exactly the thing you want to cut and paste into an email or anything else.

So what I do is copy that URL (and there isn't even a button to make copying easy) and put it into the browser's URL field. I then let the Google Maps web app go to that URL and then I create a shortened URL with bit.ly.

That's a lot of extra work for something that I expect is a very typical use case for many people.

So here's the question. Is there an easier way to do this that I am just not seeing? Or should Google make this easier?

Please let me know your thoughts in the comments.

In a typical business organization there are two levels of project management hierarchy.  You have the Executives—the COO, CTO, CIO, CFO, or some other senior level position—and then you have the project teams, with project managers and team members.  

Often these two levels never meet, rarely speak, and poorly align their objectives.  The Executives define the strategies, set the objectives and goals, analyze overall business performance, and perform some high level project selection and resource management.  On the other hand, project managers manage the planning and day-to-day activities of the individual projects.  They manage the costs of the project, measure project performance, make sure the project is on schedule, and ensure that they have the resources needed to get the job done right.

Harvey Levine said it well in his book Project Portfolio Management, “A problem common to many organizations is that there is no connection between the operations and project functions and no structured, consistent, and meaningful flow of information between the two groups.  The organization’s objectives are hardly ever communicated to the project office, and the periodic measurements made by the projects group cannot be related to these objectives.”

The disconnect between the Executives and the Project Teams cause each group to work in silos, focusing only on their own individual roles, without ever truly meeting the objectives of the company.  Are the projects supporting the goals of the Executives?  If a project is in danger, do the Executives find out about it before the project spins out of control or do they just perform damage control?  Do the project managers have the knowledge and resources to balance schedules, cost, scope, and quality parameters?

Many of the challenges associated with projects could have been prevented had the Executives communicated with the project managers.  Having a “structured, consistent, and meaningful flow of information” between the two groups will ensure that projects are completed on time, under budget, and within the project mix criteria set by the Executives.

One way of creating this alignment is to use a single project management tool that can be used by both project teams and executives.  Executives see the big picture, while project teams focus on the details.   Using an online project portfolio management software, such as @task, Executives can see every project proposed or in process and verify that each project meets the alignment criteria set by the company.   Executives can select the projects that provide the greatest value to the organization and then push the objectives of those projects down to the project managers.  Because the project is managed using the same tool the Executives use, the Executives are notified of problems as they occur and can quickly correct the problems before they become bigger.

Using the same tool, project managers are given the direction needed to successfully complete the individual projects.  The PPM software provides the flexibility needed to create and edit project schedules, monitor costs, and align resources to meet the objectives set by the Executive team.   The goals set by the Executives are the same goals by which the project managers are measured on, eliminating the confusion caused by poor communication.  Project performance measurements are the same across all levels and if the goals are changed, all parties are involved in the change.  The end result is that corporate objectives meet project team schedules. 
(author unknown)

I recently came across an opinion piece by Liza Lowery Massey called Poor Project Management Dooms Many IT Projects.

I really liked it. She had some great points in the face of high rates of IT project failure, and inconsistencies between best practices and poor results. What particularly resonated with me were her comments regarding how receptive and mature organizations are towards project management.

Here’s my personal take on it. Nobody, not even the most visionary, most knowledgeable, most strong-backed person can carry the weight of the world on their own. I think few would argue that statement, yet as project managers, how much of our time do we spend educating and reminding stakeholders of the need for their ongoing involvement?

There is a desire I’ve seen countless times (as I’m sure you have) to slough off all accountability and responsibility for the success of a project to the project manager in charge. PMs will accept it, because that’s what we’ve built our careers doing.

Take the following dialogue:

“I just want it handled,” says the executive stakeholder.

“Not a problem,” says the project manager.

In that simple transaction, the executive stakeholder has washed their hands, and the PM has allowed it. Variants of this conversation have begun, I would say, roughly 80% of the projects I’ve seen throughout my career. I’ve been dumb enough to take jobs under those circumstances, and I’ve lost jobs because I effectively suggested, “sure I’ll take the job but we need to have some changes ’round here before we start”.

As I got older and (allegedly) wiser, I stopped with the “not a problem” part, and challenged the “I just want it handled” part. Sometimes my challenge would result in disgruntled, but present, stakeholder availability. That helped (although geez don’t do me no favours, eh?) But sometimes, my challenge would result in stakeholders opening their eyes wide to the light of possibility. These champions would recruit others, go back to their respective organizations and shape them into resilient machines that would be receptive to my efforts.

On occasions where this happened, I met with not just tremendous success, but frequently our projects overachieved in some fashion. When we encountered problems, we cut through them like butter…indeed these projects were effortless to pull off, invariably resulting in prosperity for everyone involved.

From these experiences and comparisons, I’ve learned that for large projects to stand the highest success rates, organizations need to be project-aware. Everyone, from the highest-paid executive, right down through entry-level need to understand the vagaries of projects and be prepared to adapt to their influences.

That’s not a job for one person: that’s a culture shift.

As I say this, I feel like I’m providing reasons why the project manager shouldn’t have to be accountable. That’s not my intent. What so many fail to realize is, a project of any complexity needs more than just one person fighting on its behalf. That’s a recipe for failure! If the PM is successful under those conditions it may seem like they’ve only just met expectations, but the reality is they’ve done so much more. Likely at great cost to themselves.

It comes down to this: a project manager can spend their time diving into risk analysis, tearing through the project looking for issues to resolve, knocking down barriers and filling gaps (in other words, doing his or her job).

Or, the project manager can spend vast chunks of his or her time negotiating with other people why they should get involved, or make changes to their workflow, or get resources briefed and ready on the side as backup, or even just read their status reports.

Project and portfolio success means so much more than just hiring the best to do the best. While projects are transient in nature, they leave behind a legacy the organization has to live with. Stakeholders will have to contend with that legacy long after the project has closed down. That suggests stakeholders need to have every bit as much ownership of the work as the PM at the helm. They need to ensure the very fabric of their organizations are resilient enough to handle the demands of projects taking place within their walls.

I recently came across an opinion piece by Liza Lowery Massey called Poor Project Management Dooms Many IT Projects.

I really liked it. She had some great points in the face of high rates of IT project failure, and inconsistencies between best practices and poor results. What particularly resonated with me were her comments regarding how receptive and mature organizations are towards project management.

Here’s my personal take on it. Nobody, not even the most visionary, most knowledgeable, most strong-backed person can carry the weight of the world on their own. I think few would argue that statement, yet as project managers, how much of our time do we spend educating and reminding stakeholders of the need for their ongoing involvement?

There is a desire I’ve seen countless times (as I’m sure you have) to slough off all accountability and responsibility for the success of a project to the project manager in charge. PMs will accept it, because that’s what we’ve built our careers doing.

Take the following dialogue:

“I just want it handled,” says the executive stakeholder.

“Not a problem,” says the project manager.

In that simple transaction, the executive stakeholder has washed their hands, and the PM has allowed it. Variants of this conversation have begun, I would say, roughly 80% of the projects I’ve seen throughout my career. I’ve been dumb enough to take jobs under those circumstances, and I’ve lost jobs because I effectively suggested, “sure I’ll take the job but we need to have some changes ’round here before we start”.

As I got older and (allegedly) wiser, I stopped with the “not a problem” part, and challenged the “I just want it handled” part. Sometimes my challenge would result in disgruntled, but present, stakeholder availability. That helped (although geez don’t do me no favours, eh?) But sometimes, my challenge would result in stakeholders opening their eyes wide to the light of possibility. These champions would recruit others, go back to their respective organizations and shape them into resilient machines that would be receptive to my efforts.

On occasions where this happened, I met with not just tremendous success, but frequently our projects overachieved in some fashion. When we encountered problems, we cut through them like butter…indeed these projects were effortless to pull off, invariably resulting in prosperity for everyone involved.

From these experiences and comparisons, I’ve learned that for large projects to stand the highest success rates, organizations need to be project-aware. Everyone, from the highest-paid executive, right down through entry-level need to understand the vagaries of projects and be prepared to adapt to their influences.

That’s not a job for one person: that’s a culture shift.

As I say this, I feel like I’m providing reasons why the project manager shouldn’t have to be accountable. That’s not my intent. What so many fail to realize is, a project of any complexity needs more than just one person fighting on its behalf. That’s a recipe for failure! If the PM is successful under those conditions it may seem like they’ve only just met expectations, but the reality is they’ve done so much more. Likely at great cost to themselves.

It comes down to this: a project manager can spend their time diving into risk analysis, tearing through the project looking for issues to resolve, knocking down barriers and filling gaps (in other words, doing his or her job).

Or, the project manager can spend vast chunks of his or her time negotiating with other people why they should get involved, or make changes to their workflow, or get resources briefed and ready on the side as backup, or even just read their status reports.

Project and portfolio success means so much more than just hiring the best to do the best. While projects are transient in nature, they leave behind a legacy the organization has to live with. Stakeholders will have to contend with that legacy long after the project has closed down. That suggests stakeholders need to have every bit as much ownership of the work as the PM at the helm. They need to ensure the very fabric of their organizations are resilient enough to handle the demands of projects taking place within their walls.

"Don't say you don't have enough time. You have exactly the same number of hours per day that were given to Helen Keller, Louis Pasteur, Michelangelo, Leonardo da Vinci, Thomas Jefferson and Albert Einstein."

Borrowed directly from Moj Zarei-Kesheh's face Book page, Thanks Moj

"Don't say you don't have enough time. You have exactly the same number of hours per day that were given to Helen Keller, Louis Pasteur, Michelangelo, Leonardo da Vinci, Thomas Jefferson and Albert Einstein."

Borrowed directly from Moj Zarei-Kesheh's face Book page, Thanks Moj

Organizational changes are hard. The bigger the company is the stronger it defends its status quo. Humans wearing their employee hats aren’t so much different from those wearing their user hats – they like what they know, thus they don’t like changes. But there’s often someone who isn’t happy with current state.

So you are the one. You aren’t happy with the way your company works. You know what to change. You are even willing to spend significant amount of time and effort to implement The Change. You visualize the new, better, version 2.0 of your organization which will be there once you’re done. And then you rush to convince everyone to subscribe to your vision and fight with those who reject to follow you.

Stop.

That’s an easy way to lose, become frustrated, get fired, struggle to find another job and die in misery. Oh, I might have exaggerated with the last one a bit.

Every organization, even a small one, has its status quo defenders. If you want The Change you, along with your supporters, are likely outnumbered. Trying to fight every single battle will make your group non-existent, which I guess isn’t the best tactic under the sun.

I’m not saying you should sit there silently waiting for the miracle to come. Try to drop few ideas and observe how people react. It doesn’t take much of perception skills to notice who can support your ideas, who will fight you to the last breath and who doesn’t give a damn.

You will quickly notice that tiny group of your supporters and crowd of opponents. But then you at least know your situation. And you are able to choose your battles in a way which maximizes your outcome. You quickly learn which discussion can be ignored since they aren’t important. You become aware when discussion turns into flame war and it doesn’t make any sense to continue it. And finally you become sensitive to those small signals of support from people whose opinions you care about.

You learn to choose your battles.

If you choose them wisely you win more often. Way more often. And somehow people tend to care about those with a good track record.

Does it mean you should start a discussion only if chances are good for you to win? No. Sometimes you enter battleground being aware you’ll likely lose. But don’t make it a rule. If there are poker players, who never let it go, they are broke. But at the same time they play, and lose, crappy hands from time to time. That’s just cost of learning.

If you followed the article you will enter the battlefield at least knowing who you will have to face. You will be prepared. Folks on the other side probably will not. Oh, unless they read that too, but it is unlikely. Why? Because people don’t listen, don’t read and don’t learn, remember?

This Excel 2003 spreadsheet contains the representation of the same project schedule displayed as a task list, Gantt chart, and network diagram. These examples are also explained in greater detail with other information about the various types of schedules important in planning, managing, and monitoring projects in the article Examples of Project S...vaedwards

In case you haven’t heard yet, Project Management Tipoffs for the month of June goes out tomorrow (complete with accompanying podcast). The theme for the sixth month of 2010? The Need To Knows of Recruitment. Job candidates’ ears should perk up when I mention that this issue targets the so-called tricks of the trade in recruitment that job applicants can use to their own advantage. If you want a piece of this kind of newsletter action, subscribe to Tipoffs free today.

For today, have a look at an article from the May issue. One thing we’ve been doing with each issue of Project Management Tipoffs is to answer some questions from our contingent of job candidates; in May, we took on this query from Peter in Bristol: “How can I post my CV online without giving out my personal details?”

Here’s how we responded…

Thanks for your question. Contrary to popular belief, you don’t actually have to give out any additional details on your CV over and above your name, mobile number, email address and high level location (county or city). Not providing additional detail like your full address, date of birth (not required due the Age legislation laws) and National Insurance number, does not hinder your chances when looking for a new role.

The bear minimum of contact details is adequate; they let the recruiter or organisation how to contact you, what to call you and give them a rough idea of where you are located.If you find yourself in a position where further details are asked for; especially when posting a CV online, just ignore the boxes where you can or enter some other data. It’s a different situation if you are applying for a role directly with an organisation through an application form or through their CV submission process, if address details are asked for you should supply them. At least these details are not being broadcast across a job board where you have no way of knowing who is looking for them. More personal details like copies of passports, driving licence and national insurance numbers should only be asked for when a job offering is imminent. Anytime before this and you should decline, citing security and data protection reasons. OK, this might sound pompous but there really is no reason for anyone to ask for the details earlier in the recruitment process.

Remember, once you’ve given out these details, on job boards or anywhere else, it’s difficult to keep a track of who knows what about you. With the incidences like identity fraud you should do everything you can to keep your personal details under wrap. Finally, the next time you are asked for personal details in the recruitment process, ask the question; “What do you need them for at this stage?”. You’ll be surprised at the answer. Most answers are; because they can, not because the details are needed for any particular reason.

A couple of thoughts here:

• Advice and counsel on project management and recruitment matters like these from Arras People are not merely confined - nor are they exclusive to – the Tipoffs audience. Far from it: for more examples like this and/or further help & advice regarding employment-related matters and project management issues take a look at our Careers clinic / JobSearch Support Services / Careers Advice pages.
• We love getting questions like these. Email us with your questions, comments and/or diatribes, and we’ll do our best to get them published with the advice only the expertise that Arras People has can lend.

Related posts:

1. Subscribe to the podcast now! Apologies to Chris Moyles. We just wanted you to know...
2. Tipoffs: A Big Day Tomorrow A last-minute reminder for fans of great newsletters: Project Management...
3. What Can You Expect From Tipoffs Thursday? If you’ve not already signed up for Arras People‘s acclaimed...

Related posts brought to you by Yet Another Related Posts Plugin.

Knowledge workers can work from anywhere. They just need a laptop and access to the cloud (the Internet). These “CloudWorkers” are very convenient for organizations. They are highly specialized, flexible, location independent and have no overhead. So in theory you can get a fair price. Access to a global pool of flexible talent can create agility in an organization: workforce on demand.

That’s the idea.

Together with the notion of CloudWorkers comes the idea of organizations as nothing more but vehicles to facilitate talent coming together to achieve a certain purpose. An image made famous by Tom Peters. But also John Kao, author of “Innovation Nation”, explains that Google for instance is nothing more than a large bag of projects. According to Kao organizations will find itself “managing a culture of temporariness.”

A pool of flexible talent on one side, facilitating containers with a purpose on the other side.

Photography by Alan Light.

Of course, this is a very extreme picture. But even from a conceptual point of view very interesting. Temporary activities and organizations to achieve a certain goal. Now THAT sounds like a job for Project Managers!

This scenario combines many Project Management problems.

• Resourcing from a global pool.
• Managing remote, multi cultural team members.
• Virtual communication.
• Ensuring alignment.
• Operating in a relatively “public” environment that is the web.
• Team never worked together before.

And I am sure you can think of many more.

A framework for managing CloudWorkers in temporary endeavors would in my opinion be very interesting; because I think it is the future for Project Managers, and even if the future ends up beings some kind of hybrid, it addresses several topics we always face running projects.

If you just stumbled upon this posting, I’ll recommend reading the two previous posts in this series for introduction and background:

The Context Machine: The Need For A Multi Layered Model
The Context Machine: The Essence Is Context

This is definitely a work in progress, and all constructive feedback is appreciated.

Let me start by using a metaphor. An important one.

This is a story about Handsome Rob. He is not only good looking, but he is also a great get-away-car driver. If you are planning a heist and need to get away quick, Rob is your man.

In the 2003 film “The Italian Job” Rob is played by actor Jason Statham. Handsome Rob loves the thrill and especially the life style that the he can afford thanks to the robberies he participates in. But he really wants to buy an outrageous, expensive and rare car. Rob has the reputation and the ambition to be part of a robbery in Venice. Hence the title of the movie.

It is not a movie about Handsome Rob. It is a movie about cracking a safe. That is a job you cannot do alone. You need a team. Left Ear is an explosives expert, Lyle is a computer nerd, Stella is a safe cracking expert and Charlie Croker is the man with the plan. A lot goes wrong. I mean a lot. But they have to fill an entire movie.

But, as any great motion picture, they conquer all the obstacles in their quest because of all the different skills and personalities in the team. Every individual team member has his own reputation and ambition to contribute to the overall story.

This is almost a classical movie script structure. A group of people with all different story lines join forces to go onto some quest.

Like in the Italian Job, a lot can go wrong along the way. So you need a team that is resourceful. You need a resilient team. This resilience is created by diversity, in skill and background.

In the movie it is always “a ragtag crew of misfits”, as mentioned in “Yoube: An Insider’s Guide To Climbing The Charts”, including “… one guy …” who seems like he’s going to get everyone killed. … often Steve Buscemi”. But this diversity, although sometimes leading to conflicts, doesn’t break up the cohesion of the crowd. And, oh yeah, they need a plan. They need to establish some basic rules on how to communicate.

A movie needs actors. Not every actors knows just one role. He has a repertoire. For a specific movie a certain role is played. In the case of Handsome Rob; Jason Statham can play more characters, but for this movie, it’s just Rob.

Remember the earlier image of organizations as vehicles for temporary endeavors? Enter the movie studios, they go from movie to movie. They create a culture and structure in which the creative talent is hired on a movie to movie base. And they put out movie after movie.

So. Movies. Actors. Studios.

Back to projects.

I suggest we focus on three layers. Organization, temporary context (e.g. project) and the individual.

An organization has an ambition and a reputation. A reputation can be considered as publicly available information about the context of a person or organization.

An organization has a Challenge. This can be either a threat or opportunity that is the cause / reason for the temporary endeavor.

An individual has also an ambition and reputation. And he has a role in the temporary context.

The temporary context will satisfy the challenge by the individuals playing their roles. An organizational context can be best viewed as its culture, the quest and history.

Leading the temporary context.

I’ll get more into detail about leading the temporary context in future posts, but for now think about my earlier writings on creating project culture:

• The quest is the goal of the project. I call it “quest” as it also applies to e.g. online communities.
• The small circles are the individual team members. The arrows between them represent their interaction.
• The rules of engagement are the set of rules the group agreed upon for the way they interact.
• The leader (PM) can use a mix of rituals, badges (visual clues), motivation, facilitation, communication and setting the example to ensure interactions and quest are followed as agreed (explicit and implicit) by the group.
• The individual storyline is the combination of the “history” of the person (which determines his reputation) and the profile (a snapshot of who he is at this moment, the current role or expertise). The storyline moves into the direction of a persons ambition.

Next up: Interaction between the levels.

The whole purpose of using a multi scale model like this is the ability to look at the interaction between the levels.

I will cover that in the next posting in this series. But for those who are curious, the mechanisms are discussed in my previous post: context as selection and the creation of reputation.

Other people who liked this article liked these too

• Finding The Right CloudWorker"The telecommuter is dead; meet the cloudworker." - Venkatesh Rao CloudWorkers. By the amount of ...
• The Context Machine: The Essence Is ContextIn a series called The Context Machine I will summarize three years of looking for answers to the fo...
• The Case Of The Stolen ContextSometimes politicians say stupid things during newspaper interviews. Luckily, they can always claim ...

Bas de Baar is an independent consultant based in the Netherlands. He uniquely combines over a decade of project and team leadership with nearly a decade online presence in the area of Project Leadership in a global and virtual world.

The Context Machine: Leading CloudWorkers

There are lots of definitions about what project management is:

“Project management is the application of knowledge, skills, tools and techniques to project activities to meet the project requirements.” PMBOK, 4th Edition

“Project management is the discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and objectives.” Wikipedia

Yet a writer at ProjectSmart pauses to ask what project management is not:

1. An activity where you create your plan and watch it play out perfectly until the Project Complete milestone.
2. Just PMBOK Tools & Techniques
3. Loading up projects and people with meaningless process that hinders the work
4. Being in control: Unless by control you mean being inside quality control limits
5. Just schedule tracking

Would you add anything to the list of what project management is not?

Other Articles in This Series
1. The Sack.
2. The Magpie.
3. The Deer in Headlights.
4. The Hungry Vulture.
5. The Premature Solutioner.
6. The Terrier.
7. The Wanderer.
8. The Anticipator.
9. The Reluctant Puppet.

And after almost three weeks, we finally come to the end of my series on destructive project manager behaviours. I hope you’ve enjoyed the series as much as I have. This has been by no means an exhaustive list. There are dozens of other behaviours we could evaluate, and if enough of you submit your ideas in the comments section, I may revive this topic and do another series crediting the behaviours you’d like to talk about.

Chime in below! Have you identified with this series at all? Recognized your own behaviour in places, or that of others you’ve worked with? Have you found this series constructive in terms of offering points for introspection? Or do you feel behaviour analysis really has no place in the realm of project management?

While you’re thinking about that, I give you the final chapter in the series…

Image courtesy of law_keven on Flickr.

9. The Reluctant Puppet.

Here we come to, what I believe, is the single most destructive behaviour any project manager can demonstrate. The Reluctant Puppet is a project manager who wants to run a project the way he or she knows how, but who allows well-meaning stakeholders, sponsors or their own management to railroad them into a different approach.

On the surface, this behaviour sounds fairly benign. Everyone’s well meaning, and everybody wants to get along. It seems very easy to give in once for the sake of keeping the waters smooth, but the problem is, it’s never once. Once the precedent is set, the behaviour becomes expected.

Consequences:

Reluctant Puppets sit on a vicious cycle of micromanagement and erosion. Every time they allow themselves to be steered out of familiar waters, they have to do a lot more work to be able to stay afloat. This causes the puppeteers to become irritated with the resulting lower performance, and start micromanaging. The puppet’s confidence starts to slip away, which causes the puppeteers start to lose respect for him or her, micromanaging even more intensely.

There is no happy ending to this cycle. The stakeholders, sponsors and management will become too exasperated with someone they will come to see as utterly incompetent. The project manager will come to question his or her own capabilities, leading to employment risk, and possibly some serious mental health issues. The project team will be directionless, and the project will either stall or have to undergo a massive makeover to enable it to continue.

Prevention:

It may not seem like it, but the project manager is the only person who can prevent this from happening.

During the selection process, for whatever reason, the powers-that-be chose the project manager for the job. It’s possible the project manager misrepresented him or herself (that’s the first level of responsibility). But assuming the PM was genuine, he or she was selected based on the information available to the decision-makers.

Once the work starts, management will get to know the PM and will start to form better opinions. Maybe they don’t like the PMs methods or style now that they’ve seen them. Maybe they find they don’t even like the PM as a person. Their temptation to steer the project to a more familiar or comfortable direction will grow based on the amount of discomfort they feel. That’s their problem: the PM needs to remember that. There is no law that says a PM has to be universally liked to be effective. But the PM does need to stick to their comfort zone. With the massive quantities of unknown present on any project, the PM can’t afford to throw away the one thing he or she does know.

If flustered and nervous managers or stakeholders insist on pulling the PM away from their methods, the PM needs to sit down with them and be clear: “You’ve hired me to do a job, and I’m doing it the way I know how. If I step outside of my comfort zone to please you, the project will suffer. So we need to make a few decisions on how to get past this.”

That may mean the PM needs to walk away from the project. If that’s the right thing to do, my friend, I’m afraid that’s what needs to happen. But the vicious downward spiral that is the alternative will never get a chance to develop. At least not with you.

While it takes longer term thinking, the puppeteers will likely railroad someone else, and wind up with a struggling project. That PM will probably have to leave, so who do you think the puppeteers will come back to when they realize the prediction you gave them before you walked away came to pass?

Other Articles in This Series
1. The Sack.
2. The Magpie.
3. The Deer in Headlights.
4. The Hungry Vulture.
5. The Premature Solutioner.
6. The Terrier.
7. The Wanderer.
8. The Anticipator.
9. The Reluctant Puppet.

And after almost three weeks, we finally come to the end of my series on destructive project manager behaviours. I hope you’ve enjoyed the series as much as I have. This has been by no means an exhaustive list. There are dozens of other behaviours we could evaluate, and if enough of you submit your ideas in the comments section, I may revive this topic and do another series crediting the behaviours you’d like to talk about.

Chime in below! Have you identified with this series at all? Recognized your own behaviour in places, or that of others you’ve worked with? Have you found this series constructive in terms of offering points for introspection? Or do you feel behaviour analysis really has no place in the realm of project management?

While you’re thinking about that, I give you the final chapter in the series…

Image courtesy of law_keven on Flickr.

9. The Reluctant Puppet.

Here we come to, what I believe, is the single most destructive behaviour any project manager can demonstrate. The Reluctant Puppet is a project manager who wants to run a project the way he or she knows how, but who allows well-meaning stakeholders, sponsors or their own management to railroad them into a different approach.

On the surface, this behaviour sounds fairly benign. Everyone’s well meaning, and everybody wants to get along. It seems very easy to give in once for the sake of keeping the waters smooth, but the problem is, it’s never once. Once the precedent is set, the behaviour becomes expected.

Consequences:

Reluctant Puppets sit on a vicious cycle of micromanagement and erosion. Every time they allow themselves to be steered out of familiar waters, they have to do a lot more work to be able to stay afloat. This causes the puppeteers to become irritated with the resulting lower performance, and start micromanaging. The puppet’s confidence starts to slip away, which causes the puppeteers start to lose respect for him or her, micromanaging even more intensely.

There is no happy ending to this cycle. The stakeholders, sponsors and management will become too exasperated with someone they will come to see as utterly incompetent. The project manager will come to question his or her own capabilities, leading to employment risk, and possibly some serious mental health issues. The project team will be directionless, and the project will either stall or have to undergo a massive makeover to enable it to continue.

Prevention:

It may not seem like it, but the project manager is the only person who can prevent this from happening.

During the selection process, for whatever reason, the powers-that-be chose the project manager for the job. It’s possible the project manager misrepresented him or herself (that’s the first level of responsibility). But assuming the PM was genuine, he or she was selected based on the information available to the decision-makers.

Once the work starts, management will get to know the PM and will start to form better opinions. Maybe they don’t like the PMs methods or style now that they’ve seen them. Maybe they find they don’t even like the PM as a person. Their temptation to steer the project to a more familiar or comfortable direction will grow based on the amount of discomfort they feel. That’s their problem: the PM needs to remember that. There is no law that says a PM has to be universally liked to be effective. But the PM does need to stick to their comfort zone. With the massive quantities of unknown present on any project, the PM can’t afford to throw away the one thing he or she does know.

If flustered and nervous managers or stakeholders insist on pulling the PM away from their methods, the PM needs to sit down with them and be clear: “You’ve hired me to do a job, and I’m doing it the way I know how. If I step outside of my comfort zone to please you, the project will suffer. So we need to make a few decisions on how to get past this.”

That may mean the PM needs to walk away from the project. If that’s the right thing to do, my friend, I’m afraid that’s what needs to happen. But the vicious downward spiral that is the alternative will never get a chance to develop. At least not with you.

While it takes longer term thinking, the puppeteers will likely railroad someone else, and wind up with a struggling project. That PM will probably have to leave, so who do you think the puppeteers will come back to when they realize the prediction you gave them before you walked away came to pass?

In any given situation, there are a ton of things that could possibly work. One of the most successful projects I ever managed was delivered using a mix of Waterfall, Agile, and RUP. We had a existing product that our customer wanted to enhance. The customer knew exactly what they wanted and never changed their mind. The teams involved had built the original product, and they knew the code like the back of their hand.

We used a big-up-front-design, traditional estimating, and Gantt charts... even on the agile side. We did 'black box' the agile teams, but they had to inspect and adapt their way into the overall project plan. We delivered the project on the promised due date, within something like 1% of the original cost estimated, and with everything the customer had originally asked for. My company made the money they expected to make and our client made the money they expected to make.

We didn't do a death march, there were no 11th hour surprises, the deployment went exactly as expected.

Scrum is an empirical process control method. When you have a high degree of variability, and predictive planning methods are likely to fail, empirical process control can help manage and constrain the chaos and complexity, and optimize your project outcomes. It's a more expensive way of managing project outcomes, but works better when variability is high. If variability is not high, and the system is well known... it's possible Scrum is not the best choice, even on a software project.

I think part of our problem right now is that we've somehow decided that Scrum is the way to go no matter what the project characteristics. We get so enamored with the benefits the team gets from adopting Scrum, sometimes we forget that Scrum might not be well suited to the business needs of the enterprise. That's not a knock on Scrum... it's just that Scrum might not be the best tool for the job. It is up to us as organizational and project leaders to understand our options.

Project Management as Sunscreen: How to Avoid Getting Burned By Michelle LaBrosse, PMP, Founder, Cheetah Learning When the summer sun beats down, there’s always someone in the family who reminds you to put on your sunscreen. Wouldn’t it be nice if there was a way to easily avoid getting burned at work? There is. It’s called Project [...]PM Hut

1. Think only positive; leave the negative for tomorrow.
2. Go to your team-mate’s desk to discuss in lieu of writing a bureaucratic email.
3. Listen to a motivational piece of music for 15 minutes or so.
4. Read some of the best blog posts in your interest area. For example, QASpire’s post on Training which has been featured in the HR Carnival.
5. Profoundly relate with those you meet; from unknown morning walkers to your client’s best friends; regardless of his or her title.
6. Pause for a minute and rethink about what you’ve been doing for last few years. Is it aligned with your goals? Totally?
7. In the night, go to a calm place; may be the terrace, watch the sky and spend 10 minutes with yourself only.

Share and Enjoy:

See Also:

1. Contribute Beyond Your Title With Assumed Responsibility And Take The Right Decision!

The Past, the Present, and the Future of Project Management By Paul Naybour What will future hold for project management? Take a look at what history has to reveal to us to try and predict the trends for the future and then vote in our poll. 50’s: conception The 1950’s were the start of project management with the application [...]PM Hut

Through the years I have seen many people who use Microsoft Project (aka project management software) and claim they are project managers, I have also seen PMP certified people who don’t know the basics of Microsoft Project, and sadly I have seen project managers who are managing projects and don’t know the theory nor the [...]Kareem

The discussion around PMBOK and Agile Software Development management methods has a higher context.

The Five Irreducible Principles of Project Management

Any project management process or method, and any software development process or method that participates in the project management activities must provide outcomes to address these 5 irreducible principles before it can be considered credible.

1. Where are we going?

The answer to this question is to have a Plan. The Plan is the strategy for the successful completion of the project. The Plan describes where we are going, the various paths we can take to reach our destination, and the assessment points along the way to assure we are on the right path. These assessment points measures the “maturity” of the product or service against the planned maturity. This is the measure of progress – not the passage of time or consumption of money.
2. How do we get there?

The Plan states what work activities are needed to move toward to goal of the project. A good Plan tells us: what DONE looks like, what are the ACCOMPLISHMENTS? What are the CRITERIA for these ACCOMPLISHMENTS to be called "complete?"

What are the individual, dependent and , sequential steps needed to deliver the needed capabilities of the project to the customer? What are the durations, dependencies, timing, resources, and other items related to the Plan?

The idea these steps emerge is fanciful in many situations

3. Do we have enough time, resources, and money to get there?

The Plan must state the needed resources, funding, and time bounds for the success of the project. A common problem is optimism for these items. Documented procedures - no matter the document form - for estimating and planning these items is mandatory.

Understanding and managing risk for each critical component empowers management and staff to be accountable for the impacts of risks. Simple statistical models have been shown to be more correct than human judgment, so basing decisions on these models is critical to the success of the project.

4. What impediments will we encounter along the way?

Risk Management is How Adults Manage Projects - Tim Lister is the starting point. There are five fundamental principles of risk management

• Hope is not a strategy
• no single point estimate of cost or schedule can be correct without knowing the variance
• Cost, Schedule, and Technical Performance are inseparable
• Risk Management requires adherence to a well define process
• Communication of Risk is the Number One success factor of Risk Management

5. How do we know we're making progress?

What does DONE looks like for the customer, in units of measure meaningful to the customer? How would we recognize DONE when is arrives? How can we be sure we can get from here to DONE with the planned cost at the planned time?

We can only be assured we're making measurable progress if:

• We use Physical Percent Complete as our ONLY measure of progress. Tangible evidence that progress is being measured is mandatory.
• The passage of time and consumption of money are not measures of progress.
• Asking someone how much progress has been made is not a measure of progress.

In The End There Are Some Concepts To Remember

• The quality of a software system is governed by the quality of the process used to develop it. — Watts Humphrey
• If you can't describe what you are doing as a process, you don't know what you're doing. — W. Edwards Deming
• When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the stage of science. — Lord Kelvin
• In theory there is no difference between theory and practice. In practice there is. — Yogi Berra

There once was a speedy hare who bragged about how fast he could run.  Tired of hearing him boast, Slow and Steady, the tortoise, challenged him to a race.  All the animals in the forest gathered to watch.

Hare ran down the road for a while and then paused to rest.  He looked back at Slow and Steady and cried out, "How do you expect to win this race when you are walking along at your slow, slow pace?"

Hare stretched himself out alongside the road and fell asleep, thinking, "There is plenty of time to relax."

Slow and Steady walked and walked.  He never, ever stopped until he came to the finish line.

The animals who were watching cheered so loudly for Tortoise, they woke up Hare.

Hare stretched and yawned and began to run again, but it was too late.  Tortoise was over the line.

After that, Hare always reminded himself, "Don't brag about your lightening pace, for Slow and Steady won the race!"

It's natural for highly driven business leaders, motivated to succeed, to be unfailingly optimistic about their organizations ability to sprint forward on every initiative (I actually believe this level of confidence in the project team can be a good thing).  Unfortunately, always pushing project teams to rush out the gate like the Hare can sometimes be detrimental to project success.  Over the course of my career, I've noticed that a methodical, steady, and constant pace consistently produces successful results—leaving those who dash about like the Hare in the dust.

In my mind's eye, I don't see the Tortoise as plodding and unimaginative—which could be an argument against him (by those who don't understand him).  What I see is the Hare, unarguably quick out the gate, but unable to finish.

What can organizations do to avoid losing the race?  Here are a couple of suggestions:

1. Keep projects focused on attainable objectives
2. Allow time for organization and planning
3. Avoid, when possible, the random "emergency" projects that are typically the result of poor planning or knee-jerk reactions to changing circumstances
4. Empower the project team with a means to contribute to establishing their own milestones and benchmark time-lines
5. Utilize project and portfolio management tools to contribute to work management success

Are your project teams more like the Tortoise or the Hare?  Just remember that you can't brag about your lightening pace if Slow and Steady wins the race.

(author unknown)