|Posted by beyondexecution on February 1, 2014 at 11:30 AM||comments (819)|
I recently signed up for a new PM service, and as part of that service, they are sending me (translation:blitzing me) with emails about blog posts and webinars and free (!) PDUs. Can't say I blame them, they are starting a new business, and you need to build an audience to gain a predicable revenue stream for the future. The only trouble is, for me, I'm not overly interested in the content, at least at this point in time.
However, they did send off on a topic about Stakeholder Management. I did go through their blog post, and it had the regular stuff you would read about in the PMBOK Guide. Which is fine, except of all the knowledge areas, the PMBOK content on stakeholder management is THE most theoretical for PMs. There are very very few PMs who would actually take the time to do it this way. Stakeholder Management is a very touchy-feely, interpesonal skills mixed with strategic tactics, that can't easily be captured into a bunch of processes and templates. You need supporters as well as exceptional communication skills, not just above average skills.
One of the problems is that there are a lot of PMs who don't require the same exposure to stakeholder management as others. In my line of work, I probably encounter IT PMs about 50% of the time. I realize that's purely anecdotal, but that's still a large percentage, no matter what. IT projects are complex, and there's little room for errors, since that will cause all sorts of havoc downstream. But there's very little stakeholder management in the classical sense, per se.
What do I mean by that? Well, consider the business project sponsor on the other side of that. The amount of stakeholder management that side of the equation has to handle far exceeds anything the IT PM has to handle. Any time you involve Change Management aspects, there are significant stakeholder management duties that come through. Here, stakeholder management means convincing people to accept a new product, changing the way they are measured and assessed, forgetting good and bad habits, trying to develop and retain new ones, filling out new forms, new reporting requirements, old processes that have been removed, etc. You will have "enemies", you will need allies, you will need to make friends when you didn't want to. And this is stuff that you cannot possibly learn from reading a couple of processes from the PMBOK.
So at this point in time, I'd advise others to stay away from spouting PMBOK when it relates to stakeholder management. It's simply not realistic.
|Posted by beyondexecution on March 15, 2012 at 7:10 AM||comments (3)|
I had an interesting question posed to me a few weeks ago in one of my classes. One of the younger participants asked me for my opinion on the younger generation - how productive they would be in projects and what kind of methods a PM could use for motivation (we were in the HR section of the course We are talking about what's called Generation Y - those born roughly from 1980s-2000 (the last group born wholly in the 20th century). Those born around 1985-1991 should be entering into the workforce around now. I was curious about this topic before, although more from a next-generation-as-PM perspective, but I hadn't thought too much on the topic. As I tend to do, I started talking out loud as to what I think might occur.
My opinion is that the corporate culture will push many on the Gen Y's to conform, whether they like it or not. Now, I'm not saying that every company's culture is highly militant, but there's generally structure, there are performance evaluations and there are repercussions for not performing. Companies are not going to be like Google, which has a lot of employee empowerment. But Gen Ys will fall in line within the company, or leave.
(As an aside on Google, it's not all milk and honey over there. Yes, you get very flexible work hours, but people tend to be communicating 24/7 via email/instant messaging/others. The hierarchy is incredibly flat - approx 100 direct staff per manager. If you thought it was hard to get feedback before... Pay and benefits are generally regarded as lower than industry. You do get free food, but that makes you stay at the office longer. And yes, people do complain about bureaucracy, even at Google.)
Gen Ys have a stereotype that they are inattentive and easily bored, they have little or no loyalty towards a company and that they do not spend much time on tasks, thereby producing low quality work. These are things I have heard but I don't believe all of them. I will make a bit of a generalization with Gen Ys on two specific traits: they are more entrepreneurial in nature, and they are more likely to quit an organization in search of another. The latter may in fact be a symptom of the former. The entrepreneurial-ness may in fact come from changes in wealth than from demographical change. Gen Y parents have accumulated more wealth, and as a result there is more of a safety net for them. They may search around more in the first 8-10 years of their career for that perfect company, but they will find the grass is NOT greener on the other side. As a person who has worked for 8 different organizations (and volunteered with another), I can attest to that. Corporate culture usually undergoes significant change if a company has a catharsis or life-threatening event; otherwise culture changes in small increments.
So where does that leave us? I look back on my time with Accenture as a good indicator. Accenture has a HR strategy of hiring people right after university. Even when I was there back in 2004-2008, we had some folks coming in who would be Gen Y'ers. What I found is that these kids were very motivated to perform in the beginning. They would spend far more than a regular 40 hours a week in performing work as well as other "extra-curricular" organizational duties in order to get ahead. For those that didn't work out, this phase would generally last about 2 years. In 2 years time, they would either be promoted to the next level, or start to fizzle out. They would likely leave here. Some would stay to the next level for a while (about 3-4 years) and leave again. Keep in mind that Accenture has an up-or-out model, as do many other consulting companies. GE is also similar.
So I saw conformance, even though there was a different generation in place. They want to see results, through salary and promotion, and even if it is good feedback. But it will work to a certain point before trying something else. And the workforce society nowadays affords them that opportunity, to be able to have multiple companies on their resume.
The last piece I will end this post with refers to the title - The Trump Card. It overrides much of what we do, both positively and negatively. We conform, whether we like to or not. I always explain this whenever I teach as well, which is why my philosophy is to try to increase skills in thinking, not techniques or process. Process lies within an organization's control - you can't change this as much as you'd like. Take the learnings from the course, try to identify new skills, practice different techniques, but don't try to change your company's processes, it won't work. Change happens little by little, take the Kaizen approach.
|Posted by beyondexecution on March 12, 2012 at 7:30 AM||comments (47)|
In one of my recent classes, a participant was clearly very frustrated at having to "baby-sit" team members in order to have it done. She was tired of having to chase people down to remind them of deadlines and finding out issues that probably should have bee identified and actioned earlier. Her question to me what way is there (or PMI way) to avoid this situation, and let her get on with more important duties? I did not have an answer that she really liked, which was there isn't really a way around it. Part of the project manager's responsibilities, whether we like it or not, is to chase deliverable status. I called it a facilitator role, as opposed to a baby-sitter (I suppose this would depend on the maturity level of the team members
I honestly don't think there is a way around it, at least not completely. There are a few techniques that can be applied:
1. Orientation. This is a chance to set expectations of what you want team members to do, whether it be adhering to the timelines, reinforcing quality guidelines, or setting up ground rules such as attending meetings on time.
2. Training. Sometimes we get folks who simply aren’t skilled and they need to obtain the skills. Sometimes they may not be used to project life, if you are borrowing resources from a functional or operational group.
3. Rewards (Penalties). Not always doable in a large corporation, you can still find ways that don't cost money for these. Looking at rewards only (and you can create opposite approaches for penalties), methods such as positive feedback, taking a person out for coffee or even lunch, or making a recommendation to a their supervisor can work out well.
The above are what I'd call "PMI-recommended", proactive methods. Mainly academic, hit-and-miss on their results when applied to practice. They can work, but it's not a straight forward do-it-like-this approach. I think the skill of the PM comes into play here on how effective the results are.
The next few are a bit more to real life, but they are also more reactive in nature, which is usually where we find ourselves.
4. Project Performance Evaluations. These evaluations should go back to supervisors and managers, so this should, in theory, give you a bit of a carrot and stick to aid performance. This is highly dependent on a company's culture though. I do find that high performing cultures do tend to produce results. The drawback, of course, is that there's very little tolerance for poor performers, and they get shipped out pretty quickly. If you're in a culture that doesn't promote this, this tactic doesn't do much for you.
5. Peer pressure. Using social politics in your favour. Try using the team member's internal "customers" to apply pressure. By internal customers, I mean other team members who are dependant upon the person's deliverables. Their schedule will become delayed because of the person upstream from them. If you have a high performing sub-group, or cell, have them try to help out, or accordingly put pressure.
6. Negotiation. This isn't pretty for a PM to do, and that's why it's near the bottom of the list. But when you have a low amount of formal power over team members, sometimes you need to use this approach to get things done. I've used negotiation more often when I worked in a functional organization.
7. Replacement. The ultimate action. Not pretty, but you need to be willing (and have the power) to do this. See my previous blog post on when to remove a team member on things to look for -> here.
The overall results we want is to have a maturity level amongst your team members so that you can do "real" work - managing the overall project, resolving higher level issues, managing client expectations and so on. The reality is, however, that we cannot completely get away from nagging some team members.
(My last word on this subject is that the person who asked me was more junior and a bit more new to the profession. Many of the more senior folks in the room understood through experience that the ideal situation of zero nagging doesn't really exist, at least without a change in culture.)
|Posted by beyondexecution on March 6, 2012 at 12:10 AM||comments (46)|
Have you every worked with people who can't see the forest for the trees? That is, folks who tend to deal with the details and not think about the higher level principles or strategies that drive the lower level tasks? If you think in the opposite way, or if you need to determine the high level first, then this can be become frustrating if you are not able to overcome the difference.
Fortunately, I've found a way around it, which seems to work fairly effectively. It's the same approach as determining root cause - 5 Whys (sometimes also referred to as 7 Whys). This method is used by Toyota and is a critical component of problem-solving training. According to Wikipedia, the tool has seen widespread use beyond Toyota, and is now used within Kaizen, lean manufacturing, and Six Sigma. As the approach usually states, 5-7 whys is the upper limit as to how many times you need to ask. One should be able to determine the root cause within or earlier than that range.
I was recently helping my client come up with a strategy document for licensing examinations. The first draft had what I would call a lot of detailed statements, as opposed to higher level, strategic points. For example, stating an examination is computer based doesn't address the reasons for making that approach. By asking why, we find that the first level above states: To make it easier to take and easier to mark. As we continue with "whys", we find a core of high level reasoning: reduce errors/bias, increase speed of results, increase test taking flexibility and increased security.
Once each statement has a higher level reason attached, then the reasons should be grouped together to common strategic "legs" or "pillars". Ideally there should be a core group, no more than 3-5 legs in total. If there are more than 5, it might suggest 2 things:
Since the 5 Whys approach is kind of associated with Root Cause Analysis, I'd like to call this technique something else to differentiate it: "Reverse-Decomposition". This approach can be used in a number of different project management development approaches - WBS (not re-useable projects), Risk Breakdown Structure, Quality metrics, and continuous improvement programs. Perhaps I'll come up with some easy-to-remember acronym.
Good luck in using this approach.
|Posted by beyondexecution on November 10, 2011 at 10:20 AM||comments (0)|
Yesterday I presented a one day course on Conflict Resolution at the PMI Saskatchewan Professional Development Conference (PDC). As I was being introduced at the start of the day, the room assistant said as part of his opening: "and this young gentleman will be presenting..."
I cringed internally. Even though I have over 15 years of experience in project management across multiple industries, I don't look it. Part of this is due to me being of Asian descent - we are notorious for looking younger than we are. Part of it is also the image of what we think a project management trainer looks like. The typical project management trainer has over 20+ years of experience, may be retired, and certainly has a lot of grey hair to prove it. I only have a few sprinkles of grey. And part of it is that I started in project management early in my career, which for my "cohort" is a bit unusual.
Did this affect my delivery? Not at all; once I get going I concentrate on the teaching. Did it affect how others perceive me? It's hard to say. It's difficult enough as it is to build rapport in a one day course, let alone the topic content being very heavy on theory. When I teach a 2-5 day course, my PM experience has a better chance of coming through.
In the end I was very happy with my performance - I felt I did my best in preparation, offering relevant and recent examples and ultimately the delivery.
|Posted by beyondexecution on October 31, 2011 at 7:25 PM||comments (47)|
If this phrase is familiar, it's because it's one of the seven habits of highly successful people, which is a best-selling book by Stephen Covey. In the context of one of the habits, it's about self-discovery and establishing your overall values and goals. It's a very powerful technique, which is to envision the person and the success you want, then consistently moving towards that vision.
I apply this technique when I practice project management, at both a higher level and at a slightly more granular level.
From an overall project perspective, I envision what a successful project should look like, from it's overall deliverables, to the team performance, and to the customer reaction. From that very vivid picture, I can create success factors, metric targets, risks and assumptions and key dependencies.
At a more granular level, here are just a few things where they apply:
1. Meetings, particularily status meetings
3. Problem solving
4. Email writing
Let's take the first one. If I am chairing a meeting, I have a clear objective of what I want to get out of that meeting. I can work backwards to figure out what kinds of discussions and decisions need to be done in order to arrive at that objective. I can steer the meeting so that I don't go off track. And if I've accomplished my objective before the time is up, then the meeting is over. On the flip side, if I am a participant, then I want to clarify my purpose at the meeting, what opinions that I want to express and ensure others understand them, and any decisions I want to make before I leave. For me, it makes for a very focused session and a good use of my time.
On presentations, I'll imagine who my audience is, what they want to know, and what information I want them to leave with. The last part is the most important one: what good is the presentation if they walk away without understanding the key messages? From there, the slides, the content and the flow all support that end objective.
See how this works? When you start applying this technique over and over, it becomes second nature. And it makes you a much stronger communicator. See the pattern? It's all about communication and how to get your point accross.
There's a ton of other areas to apply this technique, simply try it and you'll be surprised how easily things come together, whether it's drafting emails or just conversing with others. For me, it's the most powerful way of thinking that has driven much of my success.
|Posted by beyondexecution on July 13, 2011 at 2:35 PM||comments (43)|
The title comes from a line in Adam Sandler's movie "The Waterboy". The main character's mother, in attempts to keep him on (her view) of the straight and narrow, tells him "<Fill in the blank> is the DEVIL!" The ones used in the movie were: school, football and girls.
I finished up a stint with the government (lessons learned to come in an upcoming blog post). During my time, there was a Director who wanted to avoid any shape or form of rework. This meant finding and analyzing every piece of information, making assessments on what we had or what we would need, comparing resource skillsets and developing very detailed plans. Now, I don't doubt that this is all very good and a part of due diligence. But there comes a time (or rather, too much time), when the time and cost of effort spent on this analysis, outweighs the time lost with inaction and the relatively reduced probability of major rework. In other words, 80% effort was going towards reducing the 20% chance of major rework.
Reducing rework is a noble cause. There's no doubt that reducing errors, poor direction and rework will help a project meet its objectives. But this post wants to question the notion that ALL rework is bad.
I believe if rework is planned and kept within an acceptable limit, rework can be a tool for progression. Concepts such as iterative releases or continual improvement are met with high regard; we take feedback of what is produced and build it back into the process so that greater quality is produced. In some cases, we may want to start the ball rolling, just to begin capturing feedback, because sometimes it is unknown what the process will produce. This is still rework. We just call it a different term, and it smells better.
So plan it out - Call it something different if you need to in order to gain management buy-in. Allot some time and budget for this. Indicate what is acceptable vs. unacceptable rework. Create criteria for assessing feedback and changes. Hold meetings to review what changes need to be made. And build better quality overall.
|Posted by beyondexecution on February 27, 2011 at 2:46 PM||comments (3)|
In Toronto, we had a recent trade involving our baseball team, the Blue Jays. A player by the name of Vernon Wells had been traded to the Anaheim Angels for 2 players. Trades are a normal part of the business but what made this a top-flight transaction was the contract that Vernon Wells had. He had been signed 3 years ago to a 7-year $126 million contract, with $86 million still owed to him for the next 4 years. In baseball, his contract was thought untradeable due to the sheer amount.
Now, by every account Wells was a great guy, very likeable, and able to produce, albeit inconsistently. But in no way, shape or form was he worth that kind of money, especially when compared to his peers, or competition, so to speak. When he didn't produce, he was booed mercilessly and publicly derided at times. The money paid to him limited the organization, because it tied up their money in him, when they might have been able to spend elsewhere. That being said, you can't blame him for accepting money someone was able to give him.
The point of this? Many times we experience this on our projects, whether it is an expensive internal resource, to a contractor, to a sub-contracted vendor. You're paying top-notch dollars for a lot less in return. And you can't just trade the not-worth-that-kind-of-money resource away.
So what to do? First step is to face the big ugly naked truth and provide the feedback directly. This is tricky when there are contracts in place but still can be done (please have the foresight to include some sort of feedback and acceptance criteria in contracts). Lay out the expectations and an improvement plan. If they still can't cut it, then you've got some tougher decisions to make. Internally, you might be able to dump them. You can cut a contractor. With vendors, read the contract. Hopefully, you've structured the contract(s) to be flexible for you. A few ways this can be done:
- pay by deliverable
- acceptance criteria of deliverables
- interview/review of assigned resources before deployment
- initial "try-out" period, eg 30 days
- cancellation clause
There are lots more I'm sure. For signs of poor performance and how to give feedback, check out other sections of this site.
Get your money's worth! Don't get stuck like my Blue Jays did!
|Posted by beyondexecution on February 3, 2011 at 11:27 AM||comments (38)|
As an instructor, I'm very aware that what is taught is on paper only (these days, I guess the analogy is a Word document only) and what is done in real life varies depending on the situation. This is especially true when managing project risk. There is a ton of project management activities that "should" be done, but aren't due to time constraints and overhead burdens.
Since taking a delivery position, I am again faced with these situations and challenges again. Right now, I am tasked with developing the project management plan for my part of the program. If it were myself, I'd probably whip something up, high level, within a week and build in details as I go.
But I've found that it's not that simple. First reason: I'm not the only one. I'm managing a program and have 7 other leads under me. Some are PMs and others are technical leads. Some are ok developing the scope and timeline without much to start with, others are very risk adverse and don't want to commit to a schedule, while others just want to deliver without bothering to create a plan. And of course there is a very high degree of cross-action and dependency between their projects.
We are beginning requirements gathering sessions within a few weeks. Yet we don't have a charter or a project management plan - we have scope statements, but no detailed schedule and no budget. What on earth are we thinking, right?
So, there are a few things that allow us to proceed like this. The solution is defined - there is an approved Business Case which is actually very detailed. It outlines the project context, software components, the team structure, the high level timeline, and high level risks. It could actually serve as a Charter in many ways. Another item in our favour is the timeline. This first stage of the project spans 3 years; the requirements gathering itself will last 3-4 months. The last favourable factor is the existence of a pilot/prototype that was implemented 5 years ago. It has provided a functional baseline as well as excellent lessons learned.
So from a risk perspective, we feel there is a lower risk attached to proceeding without the plan. Is this documented? Let's say I plan to as soon as I finish posting this entry. (On a side note, we don't have all our resources in place, so I am pulled in many directions, spending 50 hours a week and feeling like I'm not accomplishing much).
But this approach is starting to bite us. We are issuing Procurement SOWs to be signed. I faced some tough questions yesterday in fact. The response I got was: "How do you expect me to sign a $2.3 million contract when you can't show me a plan?"
I felt like an idiot and deservedly so. It's something that I wouldn't teach people to do, and here I was getting caught on this very basic PM principle. I hate making excuses, so I need to go back to basics and get some things done. Let my experience be a lesson to you!
|Posted by beyondexecution on January 17, 2011 at 8:10 AM||comments (4)|
Last month I was proven wrong. On the highway to work, I normally take a detour path, because the main highway route is normally very heavy. The detour is a little longer, but saves me probably 10 minutes. I take this detour all the time, because it's always true.
Now, riding on the GO Bus, which I have started doing more and more, the driver also takes this detour as well, pretty much every day. Today it didn't, and I was thinking "No! What are you doing?!" As we drove by the exit point for the detour, I noticed a huge logjam of cars, and so the driver took the "baseline" route. The baseline route wasn't smooth sailing, but it wasn't complete stoppage as well. I'd estimate it even took a little less time as taking the detour on a regular day.
And so this made me think about how I had become conditioned in my thinking. I was so used to seeing something occur that it became the norm, until I saw proof otherwise. Think about it - we are doing this all the time in how we make decisions, which options to take and even how we view the people (the famous "Halo effect").
This also happened to NASA leading up to the (first) space shuttle disaster, Columbia. The risk around the 'O' ring at fault never changed - only NASA's perception of it. Because it never failed in previous tests and launches, NASA became conditioned that it was a low risk area. And we know what happened.
So, what's the advice here? Think objectively, be open to new data, new ideas and revisit previously failed approaches. You never know, just as I found out this morning.