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

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

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

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

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

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

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

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)

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)

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)

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)

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

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)