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…

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.

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

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

One particular Monday,
You: Can you give me a total estimate of the effort needed for your team to complete this task?
Team A lead: It will take 10 days.
(You both discuss more stuff, but this is just the simplified gist to highlight the point made in this post)

Two weeks later, on Friday, reviewing a few reports for the prior weeks

What just happened? A total disconnect between effort and duration. I can cite countless other examples when clients have been quoted timelines and costs based on flaky estimates; when project baselines have been developed without clarifying whether the time quoted was effort or duration.  Let’s explore the rest of the conversation (adapted from a real conversation).

Following Monday,
You:  So, the time you quoted me two weeks back, was that effort or duration?
Team A lead:  What do you mean?  I am not sure, it was both.
You:  Can’t be.  In the last two weeks you spent $30K getting the work done, instead of the allocated $10K.  How many resources did you have working on this?
Team A lead:  3 resources.
You:  Exactly.  Each resource on your team costs $1000/day.  If your effort was 10 days worth of work, and you employed 3 resources simultaneously to do that work, it would be completed in 3.33 days at a cost of $10K.  Instead your effort was 30 days worth of work and with 3 dedicated resources it was completed in a 10 day duration, thus costing us $30K.  This just shot our budget by $20K.

Admittedly, this post contains a very simple thought and some points of contention i.e. who could have done things differently, what could have been done better, when things could have been caught or rectified, etc. etc.  But exploring it all would be like publishing a research paper, not a blog post.  So to contain this, I purposely simplified it to point out one fundamental issue I have observed repeatedly – effort is not duration, and duration is not effort.  On large complex projects with many teams and resources getting to this granular detail is tougher than it seems, and many times it is categorized as “not worth it”.  Often you will ask for effort, but only get duration back because some team managers don’t want to commit to such an undertaking.  I cannot emphasize enough the importance of looking into both, and tracking both as frequently as permissible. 

In conclusion,
du⋅ra⋅tion [doo-rey-shuhn, dyoo-] – noun
the length of time something continues or exists

ef⋅fort [ef-ert] – noun
the amount of exertion expended for a specified purpose

Most people realize the difference, what they fail to realize is the importance.

I encourage you to share what your experiences have been in trying to get estimates from other teams: the challenges, the good, the bad, the ugly.  Your comments end e-mails help me research and write more about what’s pertinent to you.  Appreciate all the messages you have sent me thus far.  Hope to continue to provide material you care about. – 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)

Weighing the pros and cons of applying a combination of techniques from Waterfall, PMBOK, Lean, Agile or other methods is outside the scope of a blog post.  However, in researching the benefits of marrying some techniques from various methodologies, IMO it’s worth taking a para out of agile when it comes to handling customization.

By focusing on iterative releases, agile methods create room for changes to be incorporated into the development process.  They maintain good visibility of features implemented and backlogged.  By using a collaborative team and involving customers in product demos before the end of an iteration, agile practitioners ensure customers drive the end deliverable.  Viewing agile through this lens for now, what can you incorporate into your project management technique to handle customization better?

When new requests put the scope at risk, customers are often told to wait till the next requirements cycle or the end of the project.  IMO don’t make customers wait – capture all requests as wish list items at the time of request.  Categorize requirements as must-haves and nice-to-haves.   As soon as feasible, establish a release plan – a second round of development – during which these requests can be addressed (in release 1.5 after release 1.0 or a quick-fix after the release).

As you transition from phase to phase, establish go/no-go checkpoints.  At these checkpoints involve customers or stakeholders – show product demos, get feedback.  You will be surprised how some of the quick wins can reap rich rewards without much deviation from the baseline.  Besides, your customers will be happier that you listened to them even if you can’t deliver everything right away.

I don’t think there’s a one-size fits all solution.  What works for you may not work for a project manager in another industry or environment.  Nonetheless, there’s more in common than meets the eye, and takeaways from one approach will benefit the other, and the project manager’s skills.

Tomorrow – Handling Customization: Bagging the Quick Wins – CSF vs. LOE grid

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

Any customization handling request discussion is not complete without exploring steering committees.  Who should be on them?  Why are they important?  How frequently should the committee meet?

Steering committees should include a development manager, professional services manager, client or project manager (and/or program manager), sales/account executive and project sponsor/senior executive.  The sales executive and client (or project/program/account) manager knows the customer’s pulse.  The development and professional services managers help assess functionality’s LOE and feasibility.  Project sponsors or senior executives help create alignment with broader strategic goals.  Collectively, the committee creates a structure for planning resources, funds, timelines and priorities.

Steering committees help teams and companies of all sizes, from start-ups to multi-nationals.  In small companies, they avoid development going in one direction with the product while the customer wanting something different.  In large companies, they help manage scope creep and last minute changes.  In any organization, they help the project manager or client manager better manage stakeholder’s or customer’s expectations.  Because the committee meets frequently and keeps good documentation (they don’t? BAAAD Committee) there is a traceable record of how the requests were handled.  This helps with communication and avoids things slipping through the cracks.

Steering committees can meet weekly, bi-weekly or monthly – it depends on the project and organization.  In most cases I recommend meetings be bi-weekly.  This avoids blocking key people for longer durations, while allowing everyone sufficient time to follow up on the committee’s action items and prepare for the next meeting.

Tomorrow – Handling Customization: Taking a para out of Agile

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

Since my last Friday flare-up was on handling customization, this week I’ll explore some basic actionable steps to build into your processes (to handle customization successfully, duh!).

How does one address customer requests in a structured manner?  Establish bi-weekly calls with your customers.  During the calls inform them about new developments at your company.  Ask them about their needs.  Document their requests as wish list items so these requests are traceable.  Assess which requirements are in greater demand – maybe multiple customers are asking for them.  

Take these items to your organization’s professional services or development teams, or steering committees.  Push for them to be incorporated into your product or service.  In follow up meetings, proactively give your customers a status update.  Give them an approximate idea of the timeframe and costs.  Do not hesitate to quote a price.  There will always be room to negotiate.  Prior research into the customer’s budget, functionality’s market appeal and cost will help negotiate better.

Tomorrow – Handling Customization: Steering Committees

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