PoddarCo

Just couple weeks back, I was talking to a PMO Director at a large media and publishing company – we were discussing how to improve the quality of project plans put together by her team. One point she mentioned in our conversation was that of relevance. It is a simple yet extremely important concept, hence sharing it here.

She said that good, experienced PMs soon develop a knack for realizing which aspects of a project plan are important or relevant to the project at hand. For example, not all projects need detailed communication plans, stakeholder registers or extremely detailed project schedules. To manage one’s workload efficiently it is important for the PM to realize what applies and adds value to the project, and produce those components of the plan accordingly.

It is a simple thought but often overlooked. Click here to read a related post on what we identified as core things to look for in a basic project schedule

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

Recently, I was working with a PMO Director on improving the quality of her team’s project schedules (built using MS Project). Note that these schedules were fairly basic, so we are not talking about complex cost tracking, WBS linkage and resource leveling. At this point, the goal was just to identify the most critical pieces to capture on a project schedule given this company’s structure and operations. Working in conjunction with other project managers on her team, we identified the following as critical components that even the most basic schedule should reflect:

1. Have adequate coverage of all activities and milestones critical to the project (see note below regarding what level to track at)
2. For each activity, clearly capture estimated duration and effort. In this organization getting an accurate indication of effort was quite challenging, so duration was used more often. While this presents some resource management challenges, it was an acceptable approach given the realities of the organization.
3. It is also important to indicate the dependencies / predecessors so all activities and milestones are clearly linked to each other. This not only makes it easier to administer changes to the plan but also to assess impact of any slippage very quickly.
4. For all activities identify the resource accountable for the activity’s completion. Dependent on how you do this, and how you set up other linkages in the MS Project file, assigning resources can also help you in estimating costs, in preparing budgets and in resource leveling.

One can do a lot more with MS Project, but we identified these as the most basic requirements given the organization’s and the project team’s needs.

Another important point underlying all this was the level at which to track activities in the project schedule. This depends on the needs of the project – some projects warrant detailed task level tracking, while for others, tracking by deliverables/milestones works just as well. The level at which you track is also a function of which methodology your organization is using as the rules of the game may differ. Although, the gist of it stays the same – what needs to be done, how long will it take, what are the dependencies, who is accountable.

Related posts that you might want to browse through -

• Managing Projects – by tasks or by deliverables and milestones

• Relevance as a skill for PMs

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

Recently I attended an event led by a New York University Professor. Here I had the opportunity to listen to two of the best entrepreneurs in NYC (Barry Silbert – Founder and CEO of Second Market, and Marc Cenedella Founder and CEO of The Ladders). A lot of valuable insights came out of this, but one very simple piece of advice really stood out – and the best part is it can help everyone, no matter at what level of the organization.

Have you ever thought that things would improve if only you could change something in your organization but you did not know where or how to get started? Here’s the tip: Think, if you were to get fired, what would your replacement do? Would he or she run things the same way, or would they immediately change something and how would they go about it?

Perhaps this simple question will give you the drive you need to actually execute the change. Go for it – be the change agent your organization needs!

Also, I am planning to attend another exciting event soon! Click here to read more about it…!

Click the image to read about some of the speakers at this upcoming event -

The complete list of speakers at the event -

• DOUG AKIN Chief Engagement Officer, Mr Youth
• KRYSTAL BALL Congressional Candidate
• MATTHEW BISHOP New York Bureau Chief, The Economist
• JANE BUCKINGHAM Founder, Trendera
• JARED COHEN U.S. State Department, Project Lead: ‘Text Haiti to 90999′
• CINDY GALLOP Founder & CEO, IfWeRanTheWorld
• SCOTT GALLOWAY Founder, L2
• BEN KAUFMAN Entreprenuer-in-Chief, Quirky.com
• STERLING LANIER President, Chatter
• LAURA McEWEN Publisher, TeenVogue
• DR. JAY PARKINSON Founder, HelloHealth
• ERIN SCHRODE Founder, Teens Turning Green
• GREG SHOVE CEO, Halogen Network
• ADAM WALDEN General Manager, Noise Marketing
• ANDREW WAGNER Editor in Chief, ReadyMade
• MARK ZANDI Chief Economist, Moody’s Analytics

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

Generally in software development projects, it is no surprise that it is harder to release the first iteration of a software than future iterations.  The team is new, often the technology is new, requirements and processes are vague, uncertainties cloud post-release adoption, a fair share of skeptics spot the user landscape and in general it is hard for everyone to see true progress.

So, why mention version 1.0 software releases and how they relate to a project manager or to a project management organization (PMO)?

Well, version 1.0 releases generally require the project manager to tweak their normal project management approach and build more flexibility in almost all facets of the project. They require the project manager to wear multiple hats – often taking part in requirements capture, user interface design, market studies, application testing, training and other duties that might otherwise be deemed to be beyond day-to-day project management activities.

From a PMO’s perspective, the PMO leader should guide project managers in these areas as necessary. The PMO leader should also realize that the needs of such projects are different, and ensure that the PMO’s own processes do not stifle progress on the project.  Some areas to be conscious of in this regard are -

• a PMO that establishes a hard stance on no scope changes – requirements will shift constantly on 1.0 releases, so at times, scope will change too. The key is to re-prioritize what can be delivered in the software’s first release given all project constraints, and embrace the highest priority must-have changes.
• a PMO that has rigid processes around how and when code updates move through various environments (such as development, integration, quality assurance / testing, staging, production, disaster recovery) – it is understandable for organizations to have strict controls on what gets implemented in their staging, production or disaster recovery environments. However, IMO, it helps maintain momentum if code is allowed to move quickly from development to integration to quality assurance environments. This could be set up as an exception to the norm, only applicable for certain such projects.
• a PMO leader may need to provide additional coaching – for reasons mentioned earlier in this post a PMO leader may need to spend more time with project managers coaching them in areas outside their domain. Simple endeavors such as value stream mapping, building flowcharts and workflows, using dashboards with critical metrics to measure and communicate progress, and various other techniques mentioned in several project management publications can be very effective in building team morale, creating a common vision and balancing expectations, especially when uncertainty runs high prior to a software application’s first release!

In fact, balancing expectations is so crucial that its worth highlighting a few points on it. Depending on the nature of the project, you might have a sponsor that constantly micro manages every aspect of the project, or one that just wanted the finished goods yesterday.  In 9 out of 10 cases, I have observed that software applications in their first release or initial rounds of major cutting edge technological upgrades tend to be pretty close to a sponsor’s heart. It is important for the project manager to realize these situations, as they demand extra facilitation and frequent expectation reseting, whether it be in terms of budget, timeline or resources.

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

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

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)