PoddarCo

Various publications term project management to be leadership without authority.  Authority or no authority, as leaders project managers constantly have to make decisions, and facilitate others to help them make decisions as well. Recently I read a good summary of various decision making levels and thought I’d share this with everyone.

Gordon, Miller and Mintzberg defined three levels of decision making: operative, administrative and strategic. Some of the characteristics of decisions at these levels are:

As a project manager, it helps to be aware of these decision making levels when you work with everyone on your team, on other teams or in different companies.  If you get a chance, try to read more about decision making.  In the near future, I’ll post another short blurb on some behavioral factors that influence decision making. 

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down.)

Background

A software development project requires rolling out a new software application to a user base of 3000 people globally in the first phase, and then expanding to another 2500 users potentially. This application uses SharePoint 2010 and Office 2010 as its technical foundation. The software also relies on a virtualization solution provided by another vendor. The users have Office 2003 and Windows XP on their computers. The company has about 15000 employees globally; most using a combination of Windows XP and Office 2003 or Office 2007 on their computers.

Situation

A part of the project team set up a software lab with Windows 7 and other Windows 7 dependent software based on their research. As people started using the lab for testing, and issues emerged, Windows 7 got highlighted as a cause for concern, primarily because of –

• complications involved in upgrading everyone (user base and other employees) to Windows 7
• training concerns in transitioning users from Office 2003 to Office 2010
• integration issues with other legacy hardware and software
• the virtualization vendor’s Windows 7 ready solution being too late for our deployment goals

What if?

Had the team that set up the lab involved others in their decision making process from the start, they could have saved time, effort and money.  At least a couple options would have been to either start with a Windows XP solution and upgrade to a Windows 7 solution when the broader organization was ready or to communicate early enough any impact to the deployment timeline.

Often in software development projects, those close to the technology push to use the latest available tools or things that are “cool”. While I do not blindly discourage such endeavors, I can’t emphasize enough the importance to work with other department heads to ensure that the organization as a whole (and not just the software’s user community) can meet the demands of the proposed solution.

It is also important to consider if any other vendors you are dependent on will be able to complete their deliverables in time. The project referenced here used a Virtualization solution provider whose application would not be Windows 7 ready till June 2010. That timeline would delay the software deployment, which, from the very start was not acceptable to the sponsors.

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down.)

Another brief thought for the month – was reading about E Sreedharan’s successful execution of certain phases of the Delhi Metro project.  This is what was said of him and his project management style…

Sreedharan’s very high integrity, single minded commitment to work, managerial acumen and punctuality set him apart.  He creates a conducive and professional work culture, picking up the right people, motivating and rewarding them.  This, along with the freedom to innovate and no punishment for unintentional mistakes, make the employees put up their best show even with governmental salaries.

Just thought I’d share with everyone…

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down.)

All projects are supposed to be temporary but we all know just how many projects continue to live on.  And I don’t mean live on in our hearts and memories, but celebrate birthdays and anniversaries type live on.  This means that any given project will have a high likelihood of running through various project managers.  Seamless transition of projects from one PM to another is critical not just to maintain project momentum but also to keep both PMs motivated.  Further, it is a great opportunity for the team, especially the sponsors, to re-align expectations, to shift any strategy that has not been working successfully and to emphasize continuation of those strategies that have worked.

Often some PMs get excited about leaving their existing projects to pursue new ones, thus leaving the transitioning-in PM perplexed and crying mercy.  Here’s a suggested checklist of transitional items both PMs might want to explore to enable a successful and seamless transition:

• Provide a helicopter view of the project, its predecessors and successors, its past, present and future. Aim of this is to allow someone new to the project to grasp the big picture and understand where and how this particular project fits in the larger scheme of things.

• Provide functional overview – what are the main needs, requirements and goals this project aims to address

• Provide project status (including but not limited to issues, action items, risks) and share some lessons learned in managing the project thus far

• Provide team overview (Objective) – which teams are involved, how many resources are there, how are they allocated and who are the team leads if applicable.

• Provide team overview (Subjective) – which teams or team members work well independently vs. which require continuous follow up.  Any team that has consistently been late, blocked or resource starved?

• Provide architecture/infrastructure/technical overview if applicable

• Provide stakeholder/sponsor overview (Objective and Subjective) – who are the stakeholders and sponsors, what are their expectations, how easy or difficult are they to manage, what matters to them most (quality, timely delivery, frequent status updates, preference for details or high levels)

• Information on continuation of existing meetings

By no means is this list exhaustive, but just a compilation of things that came to mind at the time of writing.  Please feel free to add to this.  Once there is some input from others, I’ll summarize the checklist items in a word document under the Templates or Wiki section.

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down.)

Let me just open this post by stating that I have a strong preference for managing projects by deliverables and milestones, not by tasks.  The caveat, however, is that when I say so, I primarily refer to IT software development and implementation projects.  This approach has worked wonders for me in managing such projects across various industries such as Manufacturing, Retail, News & Media, Publishing and Oil & Gas.  I’d love to hear from you what works in other realms like Construction, Utilities, Health Care etc.

In my career, I have seen numerous PMs follow either of the two approaches, and be equally successful in their projects.  So ultimately it boils down to many factors, one of which is leadership.  I have found myself to be more trusting of people, so I tend to hold teams accountable for what I need from them (=deliverable) when (=milestone); how they get there (=the tasks) is to a certain extent, their team leader’s responsibility and accountability.  I find task level project plans either too narrowly focused or so detailed that the message gets lost.  A key attribute of preparing a project plan is to give all team members a perspective on how their individual efforts add up to the whole.  Everyone should understand what role they play, when their deliverables are due, what the dependencies are and what the impact of any delays on their part will be.

Often tasks may get delayed, dropped or re-assigned.  Deliverables and milestones however are integral to the project.  Even if the tasks leading up to the milestones change, the milestones still need to be met to satisfy the project needs and timelines.  This makes maintaining and tracking project dates much easier when the project is led by managing the deliverables and milestones.  Further if a task is delayed, there might be options to still make the deliverable date by adding another resource or working extra hours.  On the other hand, one benefit of tracking at task level is that with certain teams, it is the only way you will find out that a deliverable might get delayed before the deliverable due date because you know that a task leading to that deliverable has been delayed.  Whether that warrants a task level project plan or not becomes a situational decision at that point.  I tend to circumvent this issue by asking questions leading to this sort of information during the regular status calls, but keeping my project plans focused on deliverables and milestones.

In conclusion, my two cents: as the PM, while you need to be in tune with tasks that get delayed and try to contain them, preparing project plans and managing teams based on deliverables and milestones may make you more productive and your teams, more independent and accountable.

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down.)

Have you ever realized that there is a significant cost associated with meetings and the number of people invited to those meetings?  Consider an average salary of 100K per employee for the 8 employees invited to an hourly meeting.  This equates to $50/hour/person i.e. $400/8-person meeting.  Add to it 2 hours of prep-time for 2 out of the 8 people, leading to approximately $600/8-person meeting.  If this group meets daily for an hour, it equates to $3,000/week or $156,000/year.  Bet that is not what you consider when weighing the pros and cons of setting up meetings (I am sure at times you have good reason not to; some projects warrant frequent meetings).  But I suggest giving those frequent meetings and list of attendees a critical eye just to ensure no one’s time is being wasted.

The message through this illustration is pretty simple – minimize the number of meetings needed, invite only those whose participation is required, and lead meetings with a purpose.  Realize that at times going back n forth on a particular thought, idea, requirement, task or issue may not even be worth everyone’s time.  By this I am not suggesting don’t discuss these items; by all means discuss them but tune yourself to see when the discussion turns into a futile battle of wits and as the PM or meeting facilitator step in when the need arises.  Stress this point to the attendees and refocus the group, trying to lead the discussion to a firm decision either by consensus, compromise or authority.

Off late, I have seen numerous organizations continue to lay off employees even though the work load has increased significantly.  So, as organizations strive to get more out of each employee, and try to boost productivity, it is even more crucial to be judicious with the use of everyone’s time.  Treat it like a scarce commodity and spend it wisely.

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down.)

A buzz word in the PMO’s mission statement (j/k, let’s take a deeper look)

gov⋅ern⋅ance [guhv-er-nuh ns] –noun
1. government; exercise of authority; control.
2. a method or system of government or management

gov⋅ern [guhv-ern] –verb
1. to rule over by right of authority: to govern a nation.
2. to exercise a directing or restraining influence over; guide: the motives governing a decision.
3. to hold in check; control: to govern one’s temper.
4. to serve as or constitute a law for: the principles governing a case.

Almost all the definitions above instantly validate what you and I think project governance is about.  Still, are you confused wondering how it applies to your PMO?  What are some practical, actionable steps to create better governance?  Let’s see what the heck is under the hood.

Project governance comprises of “efforts to work with executives and senior managers to solicit and implement their guidance regarding oversight and control of project performance and project management activities” (Chapter 5: Project Governance. The Complete Project Management Office Handbook, Second Edition).  Mostly everyone realizes this.  However, many PMO’s limit governance to establishing project management guidelines, reviewing some performance metrics and checking progress against the triple constraints.  They miss out on the first half of the description above – efforts to work with executives and senior managers to solicit and implement their guidance.

Without executive involvement, the effectiveness of project governance gets limited, especially when a PMO is striving to establish itself within the organization.  Project governance is the catalyst that the PMO needs to become a viable, effective project management capability.  So, stretch the application of governance beyond setting policies and reviewing performance to using it as a relationship building strategy.  Described below is my interpretation of the project governance framework described in great detail in The Complete Project Management Office Handbook, Second Edition.  This framework efficiently breaks governance into a few practical and actionable steps.

Simple steps to better governance

Most PMOs I have come across had great project charters, policies and authority guidelines.  Some had fairly established project classification guidelines.  Hardly any had an executive control board or a formal committee ensuring business and technical alignment.  How many times have you observed project governance diminishing after the initial funding stage?  Some form of continued executive participation ensures that executives are involved not only in project selection and approval, but also in project execution and delivery.

To that end project governance is more than a buzz word.  It is critical to the PMO’s maturity, adoption and respect within the organization.  Chances are you are already doing many things that fall under governance.  As you try to further streamline your governance efforts, if any particular step leads to heart burn, let me know and I’ll research the cure.  I try to keep blog posts brief, so for more details on this read Chapter-5 from the book referenced below or e-mail your questions to me.  My email address is varunpoddar@poddarco.com.

References:
Hill, Gerard M.  The Complete Project Management Office Handbook, Second Edition. Auerbach Publications. © 2008

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down)

Getting to the common vision can be fun!

A common vision, a shared approach, mass adoption – IMO, convey very similar aspirations.  Books are written about how you can adapt your leadership style, management technique or change management strategies to accomplish these goals.  But, I found greater application and value in one simple exercise.  It’s called Design-the-box. 

Jim Highsmith and Bill Shackelford developed the Design-the-box exercise (Reference: Highsmith, Jim.  Agile Project Management: Creating Innovative Products.  Addison-Wesley, 2004) as a very effective practice to develop a common product vision.

For this exercise, assign people to several teams (team size is dependent on total participants but generally I have found 3 to 6 to be a good size).  Each team should be given a box, and be asked to prepare the front and back covers to sell the product which could be an application, a building, a restaurant (or just the menu) – basically any product or service.

Though once you get there the alignment creates positive energy

Each team should be directed to work amongst themselves to come up with a name, a graphic (logo) and a few key points for the front cover.  For the back cover, each team must record detailed features and operating requirements.  Once all teams have their individual boxes designed, all teams should work collectively as one unit to consolidate ideas from all boxes onto one box.  This one box represents the team’s common vision.

Just like in any other undertaking of this nature, in this too, participation is the key to success.  Some times to encourage participation, I try to make a small competition out of this exercise.  Criteria I have used to judge teams for their recommendations (boxes) are:  feasibility / practicality, applicability, attainability and creativity. 

Next time you want to lead your crew towards a common vision or goal, try this exercise.  If you need help tweaking it to your environment or industry, just holler – you know where to find me.  Btw, when you conduct this exercise if you want some inspiration or reference material, just pull out a few software boxes, DVD covers or books.

References:
Highsmith, Jim.  Agile Project Management: Creating Innovative Products.  Addison-Wesley, 2004

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down)

In a recent PM Network article, Professor Bud Baker mentioned a very interesting point with regards to the quality of people on teams – “The better your people, the more problems you are liable to have”. Like Professor Baker said, this statement sounded very odd at first. I pondered over it during a few train rides to work, on a long flight across the country and in my limited idle time. There was something about it that it would just not get off my mind; I couldn’t get myself to agree or disagree with the statement.

A part of me thought about all the teams where we didn’t have enough good people – how clients weren’t happy, progress was a challenge, efficiency was a stretch and projects were in a dire state. We had more than our fair share of problems, some attributed to a lack of enough good people. What we wouldn’t trade for a few very talented people. Another part of me recalled projects where we had many good, highly qualified people. Clients were delighted, project results were great and stakeholders couldn’t have been happier.

So, at first, I found myself disagreeing with Professor Baker (i.e. thinking more good people doesn’t lead to more problems). But then I realized that the project team, however, was not too happy because of some internal conflicts. At the project leadership level, we were channeling the conflict in a positive way and managing external relationships well. What I am not sure about is if the project quality would inevitably suffer, or if more good people would lead to greater problems (challenges) down the line?

In the second case some team members wanted to outshine the other; internal competition was high and egos were clashing creating a racket loud enough to make a noisy troop of monkeys sound subdued. Like Professor Baker said in his note, “all the good people (well meaning conscientious people who are eager to make a difference) wanted to make an impact and get involved; managing them is not easy and can lead to slow downs”. (A thought expressed by Cornell Colbert on a LinkedIn comment does a better job of making the context of this post clearer. So I thought I’d add it here “Professor Baker’s statement is not a call to reduce the quality of the talent on teams, but a reminder of what managers need to be cognizant of when leading all teams.”)

Anyway after putting my thoughts together, I found myself leaning towards agreeing with Professor Baker. But, still unable to take a concrete stance, I thought it best to open this up; I am very curious to hear about your experiences. (Most people commented that resolving the people problems on teams is a leadership issue, which is undisputed. Also most of us would prefer to hire the best available talent instead of compromising on project deliverables.) The question is – do you think the better your people, the more problems you are liable to have?

References:
Prof. Baker, Bud. In Praise of Small Teams. PM Network, March 2009 Volume 23, No. 3

David Jamriska – thank you for your comments; our brief exchange (on hiring people in this tough economy) also led to some thoughts voiced in this post.

(On the homepage, click speech bubble next to the title to leave comments. On the post page, scroll down)