PoddarCo

It’s December – end of year to-do’s, vacations, last minute shopping, scrambling with work requests, enjoying time with families, etc. So instead of a regular post, just a brief thought to share.

Scoping and budgeting are integral to any software release or project.  One month’s left in the calendar year, and 40% of the budget is still there to spend or lose. That doesn’t mean you rush order more hardware than you planned for.  Or you cram many extra features through development even if you don’t have the requirements flushed out or the developers / testers available.  Use left-over funds judiciously and plan project spend/cash-flow for the next year better.

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

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 bad system will beat a good person more often than not…

Recently, I came across this statement in a book, and started to think more and more about it, wondering about the statement’s validity, application and logic. Thinking out loud, many instances come to mind where this is indeed the case:

1. Corruption anywhere, for example in certain departments in India. Even a good person falls prey to the system.
2. Our building’s condo association and management team – people have the best of intentions when they join, but the established processes and rules hamper their ability to make improvements.
3. A spiraling downwards quality control process or lack of the right procedures in a software development environment – the lack of code checks, test cases, documentation, etc. can quickly affect a motivated newcomer’s good intentions.

Just sharing the thought – a bad system does beat a good person more often than not.

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

One afternoon, I was just curious to see what kind of results google returns.  Not gleaning any insights from these as the effort is not really justifiable.  Just sharing the fruit of an aimless exercise for fun.  The number is the number of search results returned by Google.

Project Management 135,000,000
“Project Management” 41,300,000

Project Manager 90,200,000
“project manager” 41,800,000

“love project management” 1,990
“hate project management” 182

Why projects fail 64,400,000
“Why projects fail” 12,600
why projects succeed 19,600,000
“why projects succeed” 1,010

pass the PMP exam 162,000
fail the PMP exam 77,600

Risk Management 81,800,000
“Risk Management” 24,200,000

Earned Value Management 14,000,000
“Earned Value Management” 248,000

“Project Management Professional” 1,010,000
“Certified Scrum Master” 37,200
“Certified Project Manager” 74,300
“PMP Certified” 99,900
“CAPM Certified” 9,600
“CSM Certified” 7,540
Agile Project Management 416,000
“Agile Project Management” 184,000

PMBOK 1,140,000

Project Management Training 59,200,000
“Project Management Training” 357,000

Project Management Jobs 60,900,000
“Project Management Jobs” 308,000
“Project Management Jobs Available” 1,510
“Available Project Management Jobs” 6   (LOL…!)

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)