PoddarCo

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

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

Just sharing a presentation I did at the Talener group. This presentation highlights some of the challenges with requirements capture processes, proposes a requirements life cycle / framework for better management, ownership and tracking of requirements and describes what constitutes a high quality requirement. The key takeaways are driven home through a simple yet effective pasta salad illustration.

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 few weeks back I posted a requirements management life cycle.  Since then many of you sent very valuable feedback.  I updated the previous diagram to reflect a more iterative and collaborative approach, especially during the Requirements Identification phase.   I also highlighted how requirements feed into other processes such as Estimating and Release Management (these processes are not addressed in this post or the white paper but stated for completeness).

Requirements Life Cycle - Updated

.

For more details on this click here to download the white paper

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

*Please note that the Requirements Life Cycle has been updated since it was originally posted here.  Please see http://www.poddarco.com/2009/07/02/requirements-life-cycle-updated/ for the latest updates.

The following is an excerpt from my next white paper on requirements.  I am trying to tie the various forms that requirements take, essentially trying to put a frame around them and bucket them in distinct phases. Thought I’d share the idea and get some feedback.

- – - Excerpt from ‘A Project Manager’s Perspective: the Importance of Early & Thorough Requirements Capture’ – - -

Requirements start out as customer or stakeholder wish lists. Wish list entries may be itemized into business requirements. Subsequently, business requirements are further defined as user stories and functional requirements, which answer the questions what, when, why, and where. Ideally, the development team will conduct feasibility studies to ensure that requirements can be satisfied. If necessary, a prototype should be produced and use cases should be developed; these should be verified with a group of users. This helps capture suggestions and allows revisions to be made earlier in the process, avoiding rework and resource wastage. It also enables the team to get preliminary end-customer validation and ensure that stakeholder expectations are being met.

Thereafter, the development team generally produces a technical requirements document, which answers the questions how and who, while reaffirming what, when, why, and where. Together, the functional requirement and technical requirement documents form the basis for testing and quality assurance. They can be used to set up test cases, end-user help guides, as well as help-desk support documents. The higher the quality of defining and clarifying requirements up-front, the better the downstream documentation, finished product, and end-user experience.

The figure below ties a project managerial perspective of the requirements life cycle to the phases described by Kusiak and Tang (2006).

Requirements Life Cycle

Kusiak and Tang (2006) describe the requirements life cycle as having three phases: requirements identification, requirements diffusion, and requirements attainment. They also highlight a very important characteristic of requirements: the evolutionary nature of requirements—that is, that a requirement may change its form, merge with other requirements, or be eliminated. The first phase of the requirements life cycle, requirements identification, is the process of capturing customer requirements using methods such as interviews, focus groups, and observation techniques. Requirements diffusion entails conversion of ambiguous customer requirements into more detailed technical requirements. The last phase of the requirements life cycle, requirements attainment, is the process of verifying that requirements have been incorporated into the final product. As stated, the figure above ties a project managerial perspective of the requirements life cycle to the phases described by Kusiak and Tang.

References:
Kusiak, A., & Tang, C. Y. (2006). Innovation in a requirement life cycle framework. Proceedings of the 5^th International Symposium on Intelligent Manufacturing Systems, IMS ‘2006, Sakarya University, Sakarya, Turkey, pp. 61-67.

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

Are you afraid of a client’s skepticism towards you when you first approach them? Do you get butterflies in your stomach wondering what would be a good way to start a dialogue? This white paper explores some basic steps you can take during your first meeting or phone call that will help you create a successful first impression — which will in turn lead to a healthy relationship.

For more details, 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 Virtual Library Resources – People Management.

Title: Hushing Butterflies When Making the Dreaded First Impression

Stakeholder management is critical to the success of any project.  Numerous projects get derailed leaving behind demoralized teams when stakeholder changes are not managed effectively and carefully.

Any change in stakeholders should alert you to: a shift in power, change in budget control, realignment of priorities and resources, or redirection of key functionality (addition of new requirements, removal of old requirements).

Projects can fail when you do not account for an important stakeholder or a new stakeholder.  Always keep a list of your stakeholders.  Know who they are and engage them frequently.

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