PoddarCo

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

This review was updated and republished as three separate posts on May 4, 2010.

The three posts are -

• A detailed review of a scrum master course (Through CollabNet with Tamara Sulaiman in April 2010)
• A detailed review of a scrum master course (Through CollabNet with Lyssa Adkins in February 2010)
• A summarized review of two scrum master courses: (1) With Lyssa Adkins in February 2010 and (2) With Tamara Sulaiman in April 2010

In February 2010 I attended a Scrum training course in NYC. Because of a snow storm, I only attended the first day of the two day training. While attending both days may have led to more advanced insights, my day-1 experience was below my expectations.

Training Offered By: Danube Technologies (now CollabNet, Inc.)
Instructor: Lyssa Adkins

Scrum Training Review - February 2010

Click here for a more detailed review of this training course with Lyssa Adkins

In April 2010, I attended the full two day training. While the training was better than the one I attended in February, I still have open questions on how to effectively implement scrum in certain environments.

Training Offered By: Danube Technologies (now CollabNet, Inc.)
Instructor: Tamara Sulaiman

Scrum Training Review - April 2010

Click here for a more detailed review of this training course with Tamara Sulaiman

In conclusion, if you are looking for more than basic framework knowledge, try to attend a scrum master course with thought leaders on the subject instead of software vendors that provide training services. Some trainers to consider are: Jeff Sutherland, Sanjiv Augustine, Alistair Cockburn, Ken Schwaber, Mike Cohn, Esther Derby, Michele Sliger.

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

Background

A software development project requires rolling out a new software application to a user base of 3000 people globally in the first phase, and then expanding to another 2500 users potentially. This application uses SharePoint 2010 and Office 2010 as its technical foundation. The software also relies on a virtualization solution provided by another vendor. The users have Office 2003 and Windows XP on their computers. The company has about 15000 employees globally; most using a combination of Windows XP and Office 2003 or Office 2007 on their computers.

Situation

A part of the project team set up a software lab with Windows 7 and other Windows 7 dependent software based on their research. As people started using the lab for testing, and issues emerged, Windows 7 got highlighted as a cause for concern, primarily because of –

• complications involved in upgrading everyone (user base and other employees) to Windows 7
• training concerns in transitioning users from Office 2003 to Office 2010
• integration issues with other legacy hardware and software
• the virtualization vendor’s Windows 7 ready solution being too late for our deployment goals

What if?

Had the team that set up the lab involved others in their decision making process from the start, they could have saved time, effort and money.  At least a couple options would have been to either start with a Windows XP solution and upgrade to a Windows 7 solution when the broader organization was ready or to communicate early enough any impact to the deployment timeline.

Often in software development projects, those close to the technology push to use the latest available tools or things that are “cool”. While I do not blindly discourage such endeavors, I can’t emphasize enough the importance to work with other department heads to ensure that the organization as a whole (and not just the software’s user community) can meet the demands of the proposed solution.

It is also important to consider if any other vendors you are dependent on will be able to complete their deliverables in time. The project referenced here used a Virtualization solution provider whose application would not be Windows 7 ready till June 2010. That timeline would delay the software deployment, which, from the very start was not acceptable to the sponsors.

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

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

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

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

Processes should exist as a catalyst for getting work done, not to slow it down. Checks and balances are needed to ensure nothing slips through the cracks, not to cover one team’s tracks so the next in line can be blamed. Documentation is prepared to pave the way for others who follow, not to constrain projects till every excruciating detail is noted.  Dates are necessary for planning, scheduling resources and aligning other work, but need to be kept real.

Some PMs get caught up in demanding these elements from their teams and resources. Releases don’t get scheduled till project codes, install instructions, help guides, dev complete dates, QA completion notices, team-to-team hand off meetings, multi-layered sign-offs and varied support procedures among other things are in place. By then the business (client) needs move on, project demands change, resources shift.

It’s here that a customer focus plays a crucial role.  A customer focus can shed new light on questions like – how can the process minimize redundancy and overhead while maximizing productivity and utilization? Does the process have to be so standardized? Where can you make the process flexible?

My two cents in conclusion: question the rigidity of processes and other must-haves; be alert to these things when they start becoming roadblocks.

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

Let me just open this post by stating that I have a strong preference for managing projects by deliverables and milestones, not by tasks.  The caveat, however, is that when I say so, I primarily refer to IT software development and implementation projects.  This approach has worked wonders for me in managing such projects across various industries such as Manufacturing, Retail, News & Media, Publishing and Oil & Gas.  I’d love to hear from you what works in other realms like Construction, Utilities, Health Care etc.

In my career, I have seen numerous PMs follow either of the two approaches, and be equally successful in their projects.  So ultimately it boils down to many factors, one of which is leadership.  I have found myself to be more trusting of people, so I tend to hold teams accountable for what I need from them (=deliverable) when (=milestone); how they get there (=the tasks) is to a certain extent, their team leader’s responsibility and accountability.  I find task level project plans either too narrowly focused or so detailed that the message gets lost.  A key attribute of preparing a project plan is to give all team members a perspective on how their individual efforts add up to the whole.  Everyone should understand what role they play, when their deliverables are due, what the dependencies are and what the impact of any delays on their part will be.

Often tasks may get delayed, dropped or re-assigned.  Deliverables and milestones however are integral to the project.  Even if the tasks leading up to the milestones change, the milestones still need to be met to satisfy the project needs and timelines.  This makes maintaining and tracking project dates much easier when the project is led by managing the deliverables and milestones.  Further if a task is delayed, there might be options to still make the deliverable date by adding another resource or working extra hours.  On the other hand, one benefit of tracking at task level is that with certain teams, it is the only way you will find out that a deliverable might get delayed before the deliverable due date because you know that a task leading to that deliverable has been delayed.  Whether that warrants a task level project plan or not becomes a situational decision at that point.  I tend to circumvent this issue by asking questions leading to this sort of information during the regular status calls, but keeping my project plans focused on deliverables and milestones.

In conclusion, my two cents: as the PM, while you need to be in tune with tasks that get delayed and try to contain them, preparing project plans and managing teams based on deliverables and milestones may make you more productive and your teams, more independent and accountable.

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

Have you ever realized that there is a significant cost associated with meetings and the number of people invited to those meetings?  Consider an average salary of 100K per employee for the 8 employees invited to an hourly meeting.  This equates to $50/hour/person i.e. $400/8-person meeting.  Add to it 2 hours of prep-time for 2 out of the 8 people, leading to approximately $600/8-person meeting.  If this group meets daily for an hour, it equates to $3,000/week or $156,000/year.  Bet that is not what you consider when weighing the pros and cons of setting up meetings (I am sure at times you have good reason not to; some projects warrant frequent meetings).  But I suggest giving those frequent meetings and list of attendees a critical eye just to ensure no one’s time is being wasted.

The message through this illustration is pretty simple – minimize the number of meetings needed, invite only those whose participation is required, and lead meetings with a purpose.  Realize that at times going back n forth on a particular thought, idea, requirement, task or issue may not even be worth everyone’s time.  By this I am not suggesting don’t discuss these items; by all means discuss them but tune yourself to see when the discussion turns into a futile battle of wits and as the PM or meeting facilitator step in when the need arises.  Stress this point to the attendees and refocus the group, trying to lead the discussion to a firm decision either by consensus, compromise or authority.

Off late, I have seen numerous organizations continue to lay off employees even though the work load has increased significantly.  So, as organizations strive to get more out of each employee, and try to boost productivity, it is even more crucial to be judicious with the use of everyone’s time.  Treat it like a scarce commodity and spend it wisely.

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

A bad system will beat a good person more often than not…

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

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

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

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