Good Requirements vs. Rework

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

This article is based on information from Hooks and Farry’s book entitled, “Customer-Centered Products.”

“Better, cheaper, faster!” “I want it yesterday!”

Everyone out there has heard one or more of these – how and when you’ve heard them depends on your industry. But they translate into the same headaches for everyone. If you are a product development manager, you must develop and deliver higher quality products in less time and for less money than you have in the past. If you are in charge of procuring products for use in your company, you must procure a quality product faster and cheaper than ever before – especially in this economy. Otherwise, you may not be able to stay in business. Read more »

Establishing Objects and Gaining Conceptual Agreement with the Client

I’m taking a little turn from purely project management concepts and thinking more in terms of the IT Consultant in general. Afterall, many of us working as project managers are at any given time part of a professional services organization that thinks of us basically as consultants to THEIR clients.

Establishing objectives is the starting point of any consulting project. It’s impossible to do anything else until and unless you know the desired ending point. Below are some specific questions to discuss with the client in order to elicit some outcome-based business objectives. Take them with you whenever you sit down with a client or potential client as you work through that initial meeting both selling your services and diving deeper into their need and expected results.

• How would conditions ideally improve as a result of this project?
• Ideally, what would you (the client) like to accomplish?
• What would be the difference in the organization if the project is successful?
• How would your customer (the client’s customer) be better served by this project?
• What is the impact you seek on return on investment/equity/sales/assets?
• What is the impact you seek on shareholder value?
• What is the market share/profitability/productivity improvement expected?
• How will you (the client) be evaluated in terms of the results of the project?
• How would your (the client’s) boss recognize the improvement?
• How would employees notice the difference?
• What precise aspects are most troubling to you – what keeps you up at night?
• What are the top three priorities to be accomplished?

In establishing conceptual agreement about the objectives of the project you are about to undertake together, you – as the consultant – are trying to ensure the following:

• The client is not expecting anything that you cannot deliver to them.
• The client is not expecting anything that is unreasonable under the circumstances and is not within the culture and environment that the project will be performed in.
• There will be no misunderstanding later about why additional work wasn’t performed. The limits and goals of the project will be understood and agreed upon.
• The client is maximizing your contribution and talents on the project so that the project is as effective as possible for the client and as lucrative as possible for you.

If you begin with carefully constructed objectives, you can then create a framework within which the project can be launched. From that, the project can progress toward the agreed upon goals and final solution and draw to a close. Boundaries can be derived from clear objectives. While it seems that a never-ending project is lucrative for you, it actually is not. If the end is never reached, then success is possibly never really understood and realized. Setting clear goals and reaching them is what leads to future work with the same client, not a seemingly ongoing project that drains their financial resources.

The Business Case Document

I’m trying to get on a roll providing our readers with some hopefully meaningful samples and templates of documents that may be needed on their projects.  These are templates that I created a few years ago – basically from information I think I probably found somewhere else…(isn’t that always the case?).

As I stated in The Project Charter Document article, if our readers have samples or templates they’d like to share, I’ll be more than happy to provide alternate versions of documents that I’m including here or examples of documents that I’m not covering…either will be much appreciated.  And I’m also very willing to send along Word doc versions of these templates to anyone who asks…just email me.

Here I am presenting a template for a Business Case Document.  If your customer is external, you may never see this or may never be involved with it.  If your customer is internal, it’s very possible that you’ll not only see it, you’ll be asked to help create it.  The key is to try to justify the existence of the project and the work to be performed.  The best way to do that is to show some cost/benefit analysis or return on investment (ROI).

This doesn’t have to be an extremely detailed document – leave that for the statement of work (SOW) and, of course, for requirements documents.  It does, however, need to speak very well to executive management and the key decision makers if there is to be any hope of kicking the project off.  Someone, somewhere, makes the final decision on whether or not to throw $$ and personnel resources at this effort and this document needs to convince them to approve that effort.

PROJECT BUSINESS CASE

[Save file name as: client name BUSINESS CASE yyyymmdd]

PROJECT DESCRIPTION

Provide a brief description of the project objectives and overall performance of the work to be performed.

SOLUTION

Describe the proposed solution.

COST MODEL

ROI SUMMARY

Describe when the break-even point of the project will occur and expected annual revenue generated by the project.

PROJECT RISKS

Describe risks that may impact the cost/benefit of the project performance.

The Project Business Case

Every project needs a business case. This may be informal – especially for small and/or internal projects. It may also be very formal, as is likely the case for very large and very visible projects run for customers outside of your organization. In most cases, the customer has put together a business case in order to gain their own funding for the project. In some cases, they’ll need your help – as the project manager – in putting together the project business case and thus justifying the project and associated expenses to others within their organization.

Below is Carl Pritchard’s take on the Business Case documentation as outlined in his book “The Project Management Communications Toolkit.” I found it to be an interesting read and hope that some PMs find this of value on the projects they are working or getting ramped to work on.

The Business Case Documentation

Purpose

The business case establishes the fundamental rationale for a course of action. It is the documented history of why a project, effort, or approach was selected. It details the objectives, the projected outcomes, and the projected investments associated with the effort. As such, it allows decision makers to examine the breadth of information currently known about the effort to determine whether or not the project is a good idea in terms of cost, benefit, and organizational objectives. It may include statements about the impacts on existing business practices, resource constraints, and environmental considerations so as to provide a comprehensive understanding of the project. In some instances, risk analysis is a key component. It is the primary document defending the rationale for the project.

Application

The business case is normally applied early in the project and may be developed by senior management, marketing groups, the project office, or by any group or organization responsible for initiating large-scale activity within the organization. Business cases in mature organizations follow consistent formats to allow managers to review multiple projects in similar contexts.

The business case will list the key proponents of the project, the sponsor, the users or beneficiaries of the project, and any deliverables. At a high level, it will describe the approach to be used and the business justification or rationale for that approach. Normally, that rationale will incorporate some form of cost/benefit analysis, although the types of cost/benefit analyses and their applications vary widely.

A general outline for a business case might look like this:

• Executive Overview
• Project Description
  • Proponent(s)
  • Sponsor(s)
  • Users/Beneficiaries
  • Deliverables and Quality Criteria
  • Rationale
  • Cost/Benefit
  • Schedule/Time Frames
  • Communications and Reporting Requirements
• Environmental Considerations
  • Project Development Environment
  • Project Implementation Environment
  • Organizational Processes
• Risk Factors/Risks
  • Risk Management Approach
  • Preliminary Risks Identified
• Assumptions

Content

The information supporting each of those outline components should be developed as objectively as possible. To achieve that, each element should be reviewed by at least one other person. The content may be expanded (or compressed) based on the business needs of the organization conducting the analysis. At a high level each section should contain the specific information discussed in the following subsections.

1.0   Executive Overview

The executive overview is a general scope statement identifying the time, cost, and requirements for the project, as well as the business need driving the effort. It should include the names of the project sponsors and project manager, as well as a description of the beneficiaries of the effort. The executive overview should provide a synopsis of the cost/benefit analysis, regardless of whether those costs and/or benefits are tangible or not.

2.0   Project Description

The project description should provide more depth on most of the issues raised in the executive overview, including the background, sources, and history for any data provided as rationale for the project or the cost/benefit analysis. This section may include cross-references to other project documentation, including draft plans, product descriptions, and stakeholder analyses or surveys.

3.0   Environmental Considerations

The cultural, technical, or physical environment may described here in depth, providing information on the practices and protocols typical within the environment.

4.0   Risk Factors/Risks

The risk approach described here may include the means and practices to

be employed for risk identification, qualification, quantification, response development, contingency allocation, and risk reassessment. Any initial or signifi

cant risks identified in developing the preliminary information (like the cost/benefit analysis) should be identified here as well.

5.0    Assumptions

Assumptions are beliefs that are held as true to allow for ongoing planning. In an effort to ensure that they have value, assumptions identified here regarding all aspects of the project (resources, environment, client culture, organizational behavior, and so on) should be validated as practicable.

Approaches

Business cases in some organizations may be voluminous and detailed. Others span only a page or two. Regardless of the level of depth, they should provide insight into the considerations that were used to determine if there is a valid business reason for moving forward with a project. They should be directed at an internal audience, because they may include information about the internal response to and structure for the customer relationship. The internal audience should, at a minimum, include the project sponsors, the project manager and executive management.

Considerations

Because the business case may contain sensitive competitive information, it should be disseminated only to those who have achieved a level of trust within the organization. The author of the document should be clearly identified, and contact information for that individual should be included as well. Although the business case is an initiating document, it should be reviewed and revisited on a regular basis to ensure that the cost/benefit analysis and proposal are still being pursued.

Ten Guidelines for Managing Passwords in the Enterprise

As a follow-up to my article entitled “The Most Serious Data Threat May be Sitting Next to You,” Mark Sanford from Click Studios sent me a link to their article on “10 Guidelines for Managing Passwords in the Enterprise.” Since data security and data integrity is a critical issue on any enterprise IT project that involves significant data – and they all do – this is extremely timely and appropriate.

Mark and Click Studios have graciously allowed for their article to be provided to the readers of PM Tips. I strongly urge you to also visit their site and the original article here.

10 Guidelines for Managing Passwords in the Enterprise

Today the world is totally dependent on information technology, and many corporations struggle to effectively manage and store passwords securely for their employees. Every other day you hear of large companies exposing customer account details to non-intended audiences, due mainly to poorly managed IT systems and processes. The confidentiality and integrity of sensitive data is paramount to the operations of any size business, and the following guidelines should be considered when choosing any type of electronic password management system (PMS).

1. Remove the need for employees to remember passwords, or even worse, write them down

A key cause of bad password management practices is many employees don’t have a system in which to records their passwords, resulting in them having to either remember them, or write them down and store them in an unsecure manner. The password management system (PMS) must provide adequate functionality, removing the need for employees to remember passwords.

2. Centralize the management of passwords

Centralization of an organization’s passwords is the first step in gaining control of the IT accounts used to operate their business, otherwise there is no visibility or governance of their usage.

3. Ensuring the integrity of sensitive data

To ensure the integrity of data stored in an electronic PMS, there are a few key things to consider:

• Passwords should be encrypted with 256bit AES encryption, and a unique Initialization Vector used for every install
• Users should authenticate against the PMS using their Microsoft Windows domain account credentials
• PMS must provide the option to use two-factor authentication for the user(s) who administer the system
• Sensitive code of the PMS should be obfuscated, to prevent reverse engineering by system or web administrators
• PMS must mitigated against system or database administrators granting themselves access to unauthorized data

4. Make the passwords easily accessible

Users must be able to get to the PMS from any location, must not rely on any client installs, and must give them quick and easy access to their passwords.

5. Must promote the use of strong passwords

The PMS must promote the use of strong passwords, of which the policy for password strength is set by the administrator(s) of the system. Visual representation of password strength must be available when entering passwords, or when reporting against, so the user is constantly reminded if a password’s strength is poor.

6. Must promote regular resetting of passwords

A key component of bad password management practices is not resetting passwords at regular intervals. The PMS must have one or more options for reminding users that passwords are about to expire.

7. Must be portable and recoverable

There is little use centralizing your organization passwords if you’re unable to get to them in case of a disaster. The PMS must provide the mechanism by which all passwords can be exported to a separate file, to be stored outside of existing IT systems – preferable with trusted security personnel.

8. Changes must be traceable and auditable

All large organizations require governance over access to IT systems, and its imperative the PMS must support traceability of all events within it, and must be easily reportable. This applies to standard usage by employees, or administration of the PMS.

9. Must be scalable

If you intend to implement an enterprise class PMS, its crucial the system can scale with your organization, otherwise your investment (time and money) may be wasted.

10. Must be simple to use

As with any IT system, acceptance by its audience is crucial to its success. Provide users with a poorly designed interface, and you will meet resistance at every step. To successfully employ a PMS and realize the benefits it can bring, the PMS must be very simple to use and provide the user community with sound help documentation if required.

(Click Studios – 18^th October 2009)