PoddarCo

So, as an update to my thoughts on scrum over the past couple weeks, I signed up for a Certified Scrum Master (CSM) course.  It is in the second week of February.  Will share my lessons learned and experiences in due time.  Looking forward to picking up some new tips and tools to use on my projects.

For those interested in reading more about Scrum, read this guide (it’s an excellent intro and overview): http://www.scrum.org/scrumguides/

Cheers!
-V

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

Over the past three years, I have implemented Scrum at start-up companies as well as large corporations.  While most of this has been in the world of software development and some in operations, every experience has been unique, always presenting different challenges and teaching something new.

There is an increasing level of buzz regarding what Scrum can and cannot do, and how it is similar to or different from other project management methodologies.  I have to admit that enforcing Scrum’s guidelines or building processes around Agile concepts has been easier in small teams and start-up companies than in large corporations.

I’ll elaborate on the challenges, what worked and what did not work in future posts.  In brief some of the main challenges included (1) an inability to integrate post-development activities such as QA/testing and release management fully into the sprint cycle, (2) the product owner and scrum master roles spilling over one another (also the product owner getting over loaded) and (3) various aspects of the organizational culture and business realities becoming not necessarily blocks, but valid constraints.

Anyway, lately, I have been considering signing up for a CSM (Certified Scrum Master) course, in the hope of learning something new and exchanging experiences with others.  I wonder what challenges other people have had in implementing Scrum or other Agile methods, and what can I fit into my practice to help clients better incorporate these methods into their process.

If you’d like to share your experience using Scrum, feel free to comment or drop me an email at varunpoddar@poddarco.com

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

Lately, quite a few non-project-managers and beginning-project-managers have asked me how to break into project management, or how to brush up on the basics of project management. By posting my thoughts through the blog, I thought I’d try to make the answer a little more collaborative. I have highlighted what are some must-have introductory skills, and stated at a high level some intermediate and advanced skills, which can be addressed further in future posts. These are still my work in progress thoughts; experienced project managers out there and beginners who have been through this phase recently, feel free to chime in with your experiences.

As the first step, I suggest understanding how a project traverses through its various stages, i.e. Initiation, Planning, Execution, Monitoring & Control and Closing; know what the goal of each phase is so you can better lead the team towards accomplishing that goal. I stress goal and not all the inputs, outputs and processes described by various methodologies. Regardless of whether you follow Agile, PMBOK, PRINCE or Waterfall approaches, projects follow a few basics: person-A dreams up a project for person-B to execute. Person-B needs to figure out how to organize the resources at his or her disposal to get the work done per person-A’s expectations. This entails reporting the vital stats at periodic intervals, and ensuring there are no loose ends. So read the theory behind what goes into a project’s beginning, middle and end, glean from that theory the practical insights that fit your environment and understand what your role is in facilitating the project through its life cycle.

Leadership, documentation and communication are probably three of the most basic skills needed to run projects successfully. From a documentation perspective, understand what are the needs of the project, of the team and of the sponsors. Some projects and sponsors will expect daily updates, others weekly. Some teams will warrant meeting and following up daily, others work better when left alone. Every project is different. This is where your leadership, communication and documentation intersect to produce what’s in the best interest of the project. At the least, know what goes into a project charter or some form of a project definition document, a status report, an issue log, a risk log and of course a project schedule. Familiarize yourself with the basics of risk identification, activity and resource scheduling, requirements capture and problem solving. Another important basic skill is being able to lead meetings whether they be weekly status calls, kick off meetings, client onsite discussions or steering committee calls. I have been quite surprised by how many PMs don’t know how to lead meetings effectively and efficiently.

IMO, intermediate project management skills focus on more elaborate risk management, issue management, team building, basic budget tracking, scope management, stakeholder management and facilitating proper project closure. Advanced project management includes budget control, detailed risk analysis, cost estimating, tracking project performance metrics through earned value management and other techniques, developing better forecasting skills and honing your project management style using a blend of best practices and methodologies. Check back again in the next few days for more posts on this theme. Btw, thanks to Soma B who unknowingly helped me get started on this series of posts…!

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

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)

A new white paper titled, “A Project Manager’s Perspective: The Importance of Early and Thorough Requirements Capture” has been uploaded to PMI and PoddarCo.

To download the paper, please click the White Papers link on the top right corner of the screen.  If you are a PMI member, you can also find the white paper under Resources – Knowledge Shelf – Requirements Management.

Brief synopsis of the white paper:
The aim of this paper is to share a project managerial perspective on requirements capture. This paper proposes a requirements life cycle (framework) for better requirements ownership and management throughout a project. It highlights the iterative nature of requirements, calls out some of the basic misconceptions and suggests areas for risk identification (as related to requirements).

The key takeaways are driven home through a simple yet effective pasta salad illustration. The paper also includes some effective tools you can use instantly: 7 criteria for a high quality requirement, checklist of 7 potential sources of risk within requirements, a sample requirements traceability matrix and 7 simple lessons for better requirements capture and management.

Hope you find this material helpful and practical.  I would love to hear your feedback.  So please feel free to reach out to me via comments on this blog or via email at varunpoddar@poddarco.com

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

 

Chillin?

This post stemmed from numerous occasions of hearing statements like:  I could use a few beers, I wish I were drunk, You’ve got to be off your rockers to work here, Just shoot me now – you get the point.  So I wondered – what if you consumed those beers or wines at the office – how would the alcohol help better manage projects, teams or work in general?  Here are some thoughts. 
 

• You could have one big team party (with alcohol) for meeting project deadlines? (I hear some Ya Rights; meeting deadlines?)
  

  Wine?

• You could muster enough courage (or shed enough inhibition) to tell stakeholders, sponsors or customers they cannot get what they want by the time they want for the price at which they want?
• You could fire an under-performing team member? Or give his supervisor a piece of your mind at his 360 degree feedback session?
• You could tell a team to buckle up, get their act together and move it – irrespective of whether or not you have direct ownership of that team?
  

  Beer?

• You could rephrase your repeated request for a date, task completion, etc. as “What the **** is taking you this long?” hoping that the aggression in your voice and language gets you a response sooner?
• You could tell the truth at a lessons learned session or a retrospective?
• You could report realistic budget figures, KPIs and other project statuses? (or the true reasons for the figures being what they are)
• You could demand/set effort and duration for all activities minus the sandbagging?

Okay, as you can imagine, this list can go on and on.  Instead it’s more fun to open this up and see what you would do.  Feel free to chime in, and add more fun, imaginative, crazy stuff.  After all it is Friday…!  I certainly have had a long week, and am ready for my first visit to the new Yankee stadium, a couple of hot dogs and a few beers!

Btw, there is another point to this besides fun.  There are many things we think we cannot do because of x, y and z.  Alcohol sheds one’s inhibitions enabling one to take on bolder initiatives (such as, at a bar, asking the hottest person to go on a date).  Add your thoughts, and revisit this page later to see what others would like to do in the work environ, and think through how many of those things you can actually do without the alcohol – some with just a little attitude adjustment, shift in focus or a little leadership/courage.

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