PoddarCo

We practiced a technique to write user stories that is worth sharing. Some of the ideas are similar to those mentioned in “The Art of Writing Use Cases”.

To get to a good user story, the following template was suggested:

AS A ___________ (leads you to think from a user perspective, identify multiple user profiles, etc.)
I WANT TO ___________ (leads to the required functionality)
SO THAT __________ (leads to the business value, desired outcome)

NEXT, layer this user story with specific ACCEPTANCE CRITERIA (the acronym SMART or INVEST may ring a bell). The acceptance criteria guide development, unit testing and writing of detailed use cases as well as test cases.

Illustrating this point with a simplified example from an actual project -
AS A story editor
I WANT TO be able to quickly search through multiple stories and filter them based on whether they are published, in-progress, internal documents, part of my contents or part of my workgroups
SO THAT I can focus more time on editing and reviewing the story rather than locating it

AC-1: Search results should load within 5 seconds
AC-2: Should be able to select multiple filters, example – published and my contents
AC-3: Search and Filters should be easily accessible as options from any screen on the application
AC-4…etc…

This approach communicates the big picture and acceptance criteria which may prove useful when working with virtual teams. However, writing these stories is only the starting point in requirements capture, and can be fairly time consuming depending on the needs of a project. It is even more helpful if you start assigning story points but talking about that would take this blog entry on a tangent, hence shutting up now…

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

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

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

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

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

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

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

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

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

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

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

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

Not all projects end well, especially in this economy. So once you realize your project is doomed, it is better to bite the bullet, evaluate the project thoroughly and consider calling it off. But doing so is definitely easier said than done!

Reasons to terminate a project prior to scheduled completion include macro-level shifts (changes in business strategy, change in priorities, loss of funding, lack of or shift of resources) or micro-level concerns (schedule delays, cost overruns, extensive resource consumption, unavailable technical capabilities – hardware, skills or software). Irrespective of the reason, it is important to suppress any blame-game once the decision to cancel a project is made. If a project is terminated properly, it can in fact have a positive impact on team morale, budgets, resources, possibly other projects or dependencies and any related future endeavors.

Thus, how you go about canceling a project is essential to seeing any positive impact from it. Some steps to aid cancellation efforts are as follows –

1. Conduct a thorough review documenting the reasons to continue vs. the reasons to cancel
2. Perform a gap analysis to better understand and document what is needed to close the project successfully from this point forward
3. Ensure you review the impact of canceling a project on other projects that depend on it.
   Example:  I once had an application development project that was dependent on a server farm being up and running.  Senior management had approved the project keeping the server farm dependency in mind as the server farm would reduce the effort and investment for this project. However, the server farm project was postponed indefinitely because of budget cuts. But the stakeholders for my project demanded their project’s needs be fulfilled even though the dependent server farm project was dropped. The dependency was lost and forgotten. This resulted in schedule delays, cost overruns, shift in requirements and an operational inconvenience as a smaller one-off instance of the proposed server farm had to be created and maintained for this one project. Had the stakeholders given this project a critical eye or had the team canceling the server farm project clearly communicated the consequences for other projects, planning would have been better and aligning expectations easier.
4. If there are numerous benefits to continuing a project, but limited funds or resources lead to termination, explore alternatives such as negotiating additional funds/resources/time, re-allocating capital, escalating challenges to the executive-level, and socializing the project’s benefits across other departments to garner more support and credibility.
5. It is absolutely critical to involve all key stakeholders in the go – no go decision making process
6. It is equally important to communicate across the organization so any unanticipated consequences can be highlighted quickly
7. Once the decision is made to terminate the project early, perform proper project closure steps. This entails -
   1. Document the lessons learned clearly
   2. Specify why the project was terminated early
   3. Outline what options/alternatives were explored
   4. Document the latest project status and results achieved
   5. Complete any financial or contractual obligations
   6. Re-allocate resources as necessary
   7. Archive all project material in the company’s knowledge base in case the same or a related project gets resumed in the future

In conclusion, the thought sums it all up, “Canceling a project isn’t a failure, but failing to cancel (properly) is”.

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

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

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

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

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

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

Regards
-V

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

Since I broke my rules regarding word limit on the last two posts, this one’s short.  I put this grid together as a quick and dirty (but effective) way to assess which change requests (CRs) a project manager should focus on, and how best to communicate reasons for doing so to senior executives – all on one PowerPoint slide.

It is self-explanatory.  So diving straight into key takeaways:  Try to get the quick win CRs into the product or application as part of the current project – at a low LOE these deliver high CSF.  Do some analysis on the difficult CRs to understand whether they are show-stoppers.  The light weight and heavy weight CRs are low on the customer’s radar.  Monitor them as they can be addressed in a future iteration, release or project.

Change Request Prioritization Grid

Click here to leave a comment (or click the speech bubble next to the title)

A conversation I heard in an elevator ride to my office: Two people were discussing the extremely cold weather in New York, when

Person 1:  I feel good thinking it’s March.  What I don’t feel good about is the 1000-page project plan I received this morning.  When I have time, maybe in another life, I’ll read it.  It’ll take me at least a few hours.

Person 2:  Hours?  Maybe days!

As they were leaving I glanced at their badges; they were both senior executives at their company.  

If you think updating lengthy project plans weekly is a trifling task (who reads them anyway?) check out the 1-page dashboard under Templates.  Many executives have complemented on its effectiveness.  Like a network diagram, inputs, outputs and many key metrics can be displayed along side processes, phases or teams (represented by hexagons).  Truly, a picture is worth a thousand words.

Click here to leave a comment (or click the speech bubble next to the title)

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)