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.)

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.)

Processes should exist as a catalyst for getting work done, not to slow it down. Checks and balances are needed to ensure nothing slips through the cracks, not to cover one team’s tracks so the next in line can be blamed. Documentation is prepared to pave the way for others who follow, not to constrain projects till every excruciating detail is noted.  Dates are necessary for planning, scheduling resources and aligning other work, but need to be kept real.

Some PMs get caught up in demanding these elements from their teams and resources. Releases don’t get scheduled till project codes, install instructions, help guides, dev complete dates, QA completion notices, team-to-team hand off meetings, multi-layered sign-offs and varied support procedures among other things are in place. By then the business (client) needs move on, project demands change, resources shift.

It’s here that a customer focus plays a crucial role.  A customer focus can shed new light on questions like – how can the process minimize redundancy and overhead while maximizing productivity and utilization? Does the process have to be so standardized? Where can you make the process flexible?

My two cents in conclusion: question the rigidity of processes and other must-haves; be alert to these things when they start becoming roadblocks.

(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.)

Not all projects end well, especially in this economy. So once you realize your project is doomed, it is better to bite the bullet, evaluate the project thoroughly and consider calling it off. But doing so is definitely easier said than done!

Reasons to terminate a project prior to scheduled completion include macro-level shifts (changes in business strategy, change in priorities, loss of funding, lack of or shift of resources) or micro-level concerns (schedule delays, cost overruns, extensive resource consumption, unavailable technical capabilities – hardware, skills or software). Irrespective of the reason, it is important to suppress any blame-game once the decision to cancel a project is made. If a project is terminated properly, it can in fact have a positive impact on team morale, budgets, resources, possibly other projects or dependencies and any related future endeavors.

Thus, how you go about canceling a project is essential to seeing any positive impact from it. Some steps to aid cancellation efforts are as follows –

1. Conduct a thorough review documenting the reasons to continue vs. the reasons to cancel
2. Perform a gap analysis to better understand and document what is needed to close the project successfully from this point forward
3. Ensure you review the impact of canceling a project on other projects that depend on it.
   Example:  I once had an application development project that was dependent on a server farm being up and running.  Senior management had approved the project keeping the server farm dependency in mind as the server farm would reduce the effort and investment for this project. However, the server farm project was postponed indefinitely because of budget cuts. But the stakeholders for my project demanded their project’s needs be fulfilled even though the dependent server farm project was dropped. The dependency was lost and forgotten. This resulted in schedule delays, cost overruns, shift in requirements and an operational inconvenience as a smaller one-off instance of the proposed server farm had to be created and maintained for this one project. Had the stakeholders given this project a critical eye or had the team canceling the server farm project clearly communicated the consequences for other projects, planning would have been better and aligning expectations easier.
4. If there are numerous benefits to continuing a project, but limited funds or resources lead to termination, explore alternatives such as negotiating additional funds/resources/time, re-allocating capital, escalating challenges to the executive-level, and socializing the project’s benefits across other departments to garner more support and credibility.
5. It is absolutely critical to involve all key stakeholders in the go – no go decision making process
6. It is equally important to communicate across the organization so any unanticipated consequences can be highlighted quickly
7. Once the decision is made to terminate the project early, perform proper project closure steps. This entails -
   1. Document the lessons learned clearly
   2. Specify why the project was terminated early
   3. Outline what options/alternatives were explored
   4. Document the latest project status and results achieved
   5. Complete any financial or contractual obligations
   6. Re-allocate resources as necessary
   7. Archive all project material in the company’s knowledge base in case the same or a related project gets resumed in the future

In conclusion, the thought sums it all up, “Canceling a project isn’t a failure, but failing to cancel (properly) is”.

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

It’s tough to imagine where to start with this one. In case some of you have been wondering why I haven’t written regularly in the last month or so, it’s primarily because of this project.

Let me start by stating this project was not one of my typical software/IT projects; this was re-modeling our condo. At a high level, this involved –

1. Demolition: Break a wall between the kitchen and living room, and remove countertop (Independent Contractor, let’s use the name C)
2. Electrical: Re-route wiring as need be (Co: Absolute)
3. Re-build: Place new granite countertop extended into living room as an island (Co: All Granite), replace kitchen appliances (Co: Lowes), fix any gaping holes and clean edges (C)
4. Flooring: Remove carpeting, install bamboo flooring (Co: Lumber Liquidators, Co: Majesty Oak)

Instead of going with just one contractor who could do it all, we decided to use agencies specializing in particular areas. The one contractor approach would have been too dependent on one entity and also worked out 50% more expensive. One of the immediate challenges: scheduling and aligning all these people to do their respective tasks per specific timelines, costs and quality standards.

…Murphy’s Law started to takes its grip…
blowing out my home theater system!

Once the demo work started, we were extremely excited as the instant change was gratifying. The electricians also started re-wiring. They should have done so after filing a permit, but contrary to the information provided to us they started without a permit. That’s when Murphy’s Law started to take its grip. The electricians hooked up the wrong pair of wires that led to blowing out my home theater system and an iron. C (the independent contractor) had patched part of the demolished wall enough so that the granite countertop could be installed. However, a part of the patched-up dry wall had to be re-cut as C had spackled it excessively after the granite folks had made their template.

In the process of breaking the dry wall, C threw a lot of the debris into the garbage disposal; this obviously conked off. After much research we decided to buy our appliances from Lowes. On the morning of the delivery Lowes called to say the fridge was damaged and they’d have to reschedule. We had decided to donate our appliances, and time it on the same day as the delivery. Sure enough, by the time of the call we had already given away the appliances. Realizing that we’d be without a fridge for a few days, we gave away a lot of the food too. By the way, when we tried disconnecting the fridge, as we shut off the valve for the water line to the ice maker, it wouldn’t shut off but just continue to leak. Since our building doesn’t have condo specific shut off valves, we had to call a plumber and pay him an unbelievable sum to replace the valve (it required pipe freezing).

…an electrical appliance
without a cord…!?!

When the appliances were finally delivered (extremely late even per the rescheduled time) the delivery guy asks me, “Do you have a cord for the range?” I was speechless as I couldn’t fathom an electrical appliance without a cord! I was informed the store clerk should have asked us which plug we need, and sent it with the range (pre-attached). We had learned not to expect any better from Lowes, and ended up getting the cord later from Home Depot and connecting it ourselves. Finally the last leg of the race started (or so we thought) – the flooring. Compared to the rest of the work, this process went smoothly over a period of 2 business days. But, miraculously, as soon as the new floors were installed, our bedroom air conditioner decided it had run its course – the compressor died. We paid a pot load to get a new air conditioner (installation happening this week). Needless to say, we are keeping our fingers crossed that the new floor doesn’t get scratched in the process.

City Inspector: “I don’t think I have been here before;
this is my first visit here, right?”

Also in the past two weeks, after a few exchanges with the VP at the electric company, the permit was filed and picked up (at least a month after the work started). The inspection was scheduled for earlier this week. As the inspector walked in, his first statement was, “I don’t think I have been here before; this is my first visit here, right?” Right off the bat, we got the sense that there would surely be another visit i.e. the inspection wouldn’t pass. That’s exactly what happened; the reasons – one of the outlets had sheet rock screws instead of metal ones, and the junction box and cables were not properly supported. So, now the electricians will be back later this week to do the needful. While all this has been going on for well over a month, at least 5 huge holes are still visible in the ceiling and side walls because the inspection has to pass first.

As we are finally getting closer to imagining that the walls will get patched up and edges cleaned, we learned that C got fired from the company he was representing and is no longer eligible to work in our building. I had already paid him 90% of the amount agreed to, since I “trusted” him. In this case, he didn’t exactly run away with the money, but another lesson learned – don’t pay in advance no matter what and who. Fortunately, we have a back-up contractor, who will finish up the work as soon as the inspection passes (again hoping this wraps up by Sat 8/21).

In summary, we now have an almost re-modeled condo that we are happy with after: the lack of proper processes being followed by the electric company, the cowboy contractor, an extremely disappointing Lowes experience, one unfriendly un-cooperative neighbor, multiple things being broken that shouldn’t have been broken (valves, garbage disposal, home theater system, iron, air-conditioner and a door) and a lot of hours spent working on do-it-yourself projects. But what a nightmare it was to live through. So I decided to share the experience as a Wayward Weekend story that others can learn from, or at the very least – find some humor in.

In spite of everything, this was a very interesting glimpse into re-modeling projects. I learned a lot about the work, the entities and the costs associated with such endeavors. Are the challenges typical in similar larger scale projects? I was always keen to pursue opportunities to flip old construction condos, plans for which have been put on hold given the economic conditions off late. But this experience and the lessons learned here will remain forever, and hopefully lead to a streamlined operation in the future. Just sharing a part of my personal life experience with a broader audience. Like a friend and co-worker said, “Here’s to living vicariously through me”  :)

Cheers
-V

(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)

By sharing one aspect of this site’s readership – where are the readers on this site coming from – I want to draw attention to two things (1) express my joy in the diversity and extent to which people are interested in reading project management content and (2) promote connecting with each other via LinkedIn, Twitter or Meetup groups.  In this digital world, there are numerous ways to network and stay connected without leaving your couch (or desk).  Make the most of what’s available – it can help you if you are looking for jobs, if you are looking to hire resources or even if you are looking to collaborate on any undertaking, be it a research paper, training course or just a conversation.

Below is a map of all unique visitors during the first full month of blogging (April).  When I started writing I wasn’t sure what kind of response to expect.  Some of you sent me personal e-mails encouraging me to keep the posts coming.  Many others opened up with your experiences.  And few others requested I conduct seminars and training sessions for your teams/organizations.  All were very positive experiences – even the ones that asked me how I could be promoting drinking at work (LOL. Sorry to bring it up again but it was just too hysterical).  Anyway, as I continue to balance writing and work, I wanted to take a moment to thank all of you.

Overall in this first full month (April) there were 2,000 of you who primarily came through three to four LinkedIn groups, Facebook or word-of-mouth.  To give some perspective to the color grades on the figure, the darkest color represents 950 people. Glad to see that project management appeals to a diverse group of people from all over the world.  If you would like to stay in touch, please feel free to add me on LinkedIn and/or Twitter (links also in top right corner).
 
Look forward to hearing from you.
Cheers!
-V

Visitors in April - World Map Overlay