Knowledge Park Greater Noida

Project Approach

noreply@blogger.com (Unknown) — Wed, 20 May 2009 08:15:00 -0700

The project approach is a section in the Project Charter that describes in words the thinking that goes into the creation of the project schedule. There are two benefits to creating an approach section. First, this information will help the client and stakeholders understand how the project will progress without having to interpret the actual schedule.

The other benefit of the project approach is that it allows the project manager and project team to lay out a high-level vision for project execution and use this vision to help create the lower-level schedule. Sometimes the project team finds it hard to build a schedule to complete the work. Creating a high-level approach first can make it easier to create the lower-level schedule second.

There are a number of ways the section can be prepared. Usually, you start off with general content about how the organization and environment will impact the project. Then you walk chronologically through the project, starting at the beginning and going to the end. Of course, you don't describe the detail at an activity level. You want to stay at the milestone, stage or phase level.

Sometimes it is difficult to get started with this section. The following information gives you more detail and examples of the areas that can be described. You will notice that much of this information may be available elsewhere, but it is in the approach section that you tie everything together in context for the benefit of the reader.

*Discuss whether any broader company initiatives or strategies impact the structure of this project.
*Identify any constraints or time-boxes in terms of budget, effort, time or quality, and the impact to the project.
*Describe any company standards that will impact how the project is executed.
*Note any company or industry best practices that will have an effect on the project.
*Describe other options for the overall approach and why you chose the options you did over the others. Note why you think this approach has the best chance of success over the others.
*Talk about how the deliverables will be supported and maintained after the project ends. Also indicate whether the approach was influenced by support and maintenance implications.
*Discuss any other related projects that are completed, in progress or pending that influenced the approach for this project and why.
*Discuss, at a high level, how the project will progress from start to end and the interdependencies between the high-level phases and stages.
*Discuss any techniques that might be of interest to the reader. For instance, if the requirements will be gathered in a three-day Joint Application Design (JAD) session, you can note this in the approach.
*Note whether new technology or new processes are being utilized and why.
*Identify any unusual staffing requirements, such as consultants or outside specialists, and explain why you need them.
*Describe the use of outsourcers, contractors or vendors, especially if they are doing significant work.
*Of course, these are ideas for the approach section. You do not need to comment on all of them and many may not be applicable to your project. The purpose of the approach is to describe these factors and the impact they have on the project schedule. This section generally is for the benefit of the reader - the writer already knows the information. There is a tendency to write this section briefly and quickly, therefore providing little value to the reader. If the writer is diligent and provides good context, this section can instead prove to be very valuable for the reader.

Deliver More than the Client Requested

noreply@blogger.com (Unknown) — Wed, 2 Jul 2008 06:50:00 -0700

Don't 'Goldplate' (Deliver More than the Client Requested)

The term goldplating refers to delivering more than what the client requested. Even though it might seem that this is a good thing, it is wrong for two reasons. First, the primary focus of the project should be to make sure that you deliver what the client wants - on time and within budget. By adding in additional work, you increase the risk that the project will not meet its deadline or budget. If you end up missing your deadline date, you will not find sympathy if you explain that the date was missed because of adding more work than the client agreed to.

Second, if you deliver more than the client expected, there is always the implication that you could have delivered what they wanted for less time and duration. if you goldplate, you are taking it upon yourself to make a business decision on what is of most value to the client. There may be some good reasons why the additional features were not included in the initial project scope. They may, in fact, be of marginal value to the client. There may be more value in having the solution completed early and for less cost. The point is that this is a client decision and not one that the project manager should make.

Under-promising and over-delivering should only apply to delivering earlier or for less money than was anticipated. It should not include delivering more requirements than were asked for. The client may, in fact, ask you to include more requirements in the solution. If they do, the new requirements should be processed through scope change management. However, the client may have other uses for the savings that are more important to them. If you can complete the project earlier or for less money than was budgeted, let the client make the decision on what to do with the good fortune.

Make Sure Quality Management Focuses on Processes, Not People

The focus of quality management is to build the right processes so that the entire team can produce the deliverables that meet the client's expectations. Therefore, if a particular deliverable has a quality problem, the project manager and project team should focus on how the project work processes can be improved - not on trying to determine who is to blame.

Most problems with quality are the result of poor or inadequate work processes, not because of the malicious act of a particular person. In fact, it is thought that at least 80% of quality problems can be resolved by changing and strengthening business processes. Less than 20% of problems are under a team member's control. Furthermore, the processes that your organization utilizes are largely determined by management. So, when workers or team members have quality problems, it is important for managers to identify the weak or broken processes involved and fix them. This is a management responsibility ' not the responsibility of the staff. This does not mean that everyone cannot be involved. However, the setting up and enforcement of business processes is primarily a management responsibility.

Consider Green Project Management Concepts

noreply@blogger.com (Unknown) — Thu, 26 Jun 2008 08:13:00 -0700

The world is going green and it appears that the United States is starting to get the message as well. We are collectively realizing that we do not have an unlimited amount of air or water or space to continue to utilize resources as we have done in the past. The pending crises of global warming merely serves as the central rallying point for an environmentally friendly movement that has been underway since at least the 1970s.

How can we apply these “green” concepts to our project management discipline? One obvious way is that we can manage green projects more efficiently. For example, if you are the project manager on a project that will result in a using less packaging in your products, it would be good if your project completed on time. The sooner that project ends, the sooner the green benefits will be achieved.

On the other hand, most project managers do not run these kinds of projects. Most of us deal with projects such as installing a new software package or upgrading network infrastructure. How can these projects become more environmentally friendly?

The answer is green project management.

Green project management is a model where we think green throughout our project and make whatever decisions make sense in a way that is friendlier to the environment. It is a way to ingrain “greenthink” into every project management process. Here are some examples:

Project Charter

I have seen many Project Charters in many templates. However, I have never seen a charter with a section on environmental concerns. Therefore, I am sure that most project managers never give it a thought as they are defining the project. I am also sure that few project sponsors give it a thought either.

But are there ways that your project can be greener is you would only think about it. For instance, if you are upgrading your network infrastructure, it is likely that some of your equipment will be obsolete. If you do what I did 20 years ago, you might take the old equipment and bury it in the middle of a big dumpster. However, maybe the better choice is to seek out a recycling company. You know what – it might even cost you a few bucks. However, if you identify it up front you can build the cost into your estimate.

Managing Issues

You know the process - identify an issue, determine the cause, estimate the impact to your project, look for alternatives, make recommendations, etc. Mow let me add a section to your Issues Resolution template to identify environmental impacts. I am not saying that every alternative will have any impact one way or the other. I am just saying to apply “greenthink” to the process.

For example, let’s say that you have an issue that will require an additional six hours of user testing to resolve. One option would be for the testers to work in the evening to complete the work with the least disruption to the schedule. Of course, you want to understand the impact of this evening testing such as poor morale and overtime pay.

If you had a section on your form for the environmental impact, you might also include the energy required to run air conditioning (or heat), lighting, water, etc. I know many of you are saying this is crazy because the costs are so low. However, it is not the costs we are worried about. It is the impact on the environment of using the extra electrical, natural gas, water, etc. I also know the impact is small, but consider that you are making these decisions along with millions of other people also making similar decisions. It could all add up. In fact, I taught a class at an Eastern European country last year where they might choose to delay the project for a day rather than use these additional natural resources.

The Point ...

The point about green project management is not that we make every decision in favor of the one that is most environmentally friendly. The point is that we start to take the environment into account instead of ignoring it. You might make most decisions the same as you do today. But there might be some decisions you would make differently. These different decisions, multiplied by tens of thousands each day across the world, can make a difference.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Make Sure Your Measures Add Value

noreply@blogger.com (Unknown) — Wed, 14 May 2008 06:43:00 -0700

Identifying, gathering and leveraging the right mix of metrics are ways to add value to a project. The value can be quantified in a number of areas including:

* Improved performance of the overall project fulfillment and delivery process
* Improved estimating for future projects
* Validation of duration, cost, effort and quality objectives for the project
* Identification and communication of best practices
* Improved client satisfaction

In general, metrics provide a more factual and quantitative basis for understanding how you are doing and the things that can be done better. Without at least some basic metric information, all discussions on performance and improvement are based on anecdotal evidence, perceptions and guesses. If you want your project's success or failure to be based on factual information, you need to determine the success criteria ahead of time and how to measure these criteria. Then collect the metrics, even if they are imperfect and imprecise. They still provide a better foundation than nothing at all.

Use the Metrics that You Collect

You don't want to collect metrics just for the sake of collecting them. That doesn’t make sense from a project management perspective and it just ends up being a waste of time. If certain metrics are required by your organization, collect them. In addition, you should collect any other metrics that are needed by your particular project. However, if you don't have a purpose for the metrics, or if your project is not long enough that you can really leverage the information, these customized project-specific metrics are not worth collecting for your project.

Compare the Cost of Collecting a Metric vs. the Benefit

Just as there is some cost associated with most project management activities, there is a cost to collecting and managing a metrics process. In the case of scope management or issues management, this is a cost the project manager needs to invest in to be successful, since they are core project management processes. The effort associated with managing metrics, however, is more under the discretion of the project manager and is dependent on the overall organizational culture. In many cases, the cost to collect and leverage a certain type of metric is prohibitive. These metrics should not be pursued. Other metrics are interesting, but do not provide the type of information that can be leveraged for improvement. The bottom line is that the cost to gather each metric must be balanced against the potential benefit that will be gained. Start by gathering metrics that are required by the organization. Then add metrics that have the lowest cost and effort to collect and can provide the highest potential benefit.

Link Team Performance with Individual Performance

This old adage about “what gets measured gets done” is true on projects. If communication is important on your project, build some metrics around communication. For instance, you can survey the clients and stakeholders on a quarterly basis to see how effective they think your communication is. If you are encouraging your team to reuse existing components, track the instances of reuse and the hour and cost savings.

However, you still may not drive the behaviors you need if the results of the metrics do not have a corresponding personal impact on the team members. The key is to collect metrics that give a quantifiable indication of overall team performance and make sure there is a connection between team performance and individual performance.

An example of where these are not linked is the classic case of the project that is seen as a failure, yet all the team members are evaluated highly on their performance reviews. Make sure that project team success is reflected appropriately in the individual performance reviews. If the team was successful, team members should be rewarded. If the team was not successful, team member reviews should be impacted accordingly.

Manage Issues - Large Projects

noreply@blogger.com (Unknown) — Wed, 7 May 2008 06:22:00 -0700

Use the following process to manage issues on large projects.

1. Identify the problem and document on the Issues Form

Solicit potential issues from any project stakeholders, including the project team, clients, sponsors, etc. The issue can be surfaced through verbal or written means, but it must be formally documented using an Issues Form.
2. Determine if the problem is really an issue

The project manager determines whether the problem can be resolved or whether it should be classified as an issue.
3. Enter the issue into the Issues Log

If it is an issue, the project manager enters the issue into the Issues Log.
4. Determine who needs to be involved in resolving the issue

The project manager determines who needs to be involved in resolving the issue. The sponsor may be involved, or the sponsor may not have the expertise to assist in the resolution process. For instance, the resolution may require technical or legal staff. The problem may be contractual and require resolution from the Purchasing Department. However, at some point the alternatives will be discussed and a resolution will be made. It is important to understand up-front who needs to be involved in making this final issue resolution.
5. Assign to team member for analysis and alternatives

The project manager assigns the issue to a project team member for investigation (the project manager could assign it to himself or herself). The team member will investigate options that are available to resolve the issue. For each option, the team member should also estimate the impact to the project in terms of budget, schedule and scope.
6. Gain agreement on resolution

The various alternatives and impact on schedule and budget are documented on the Issues Form. The project manager should take the issue, alternatives and project impact to the project sponsor and other appropriate stakeholders for discussion and resolution. The project manager may want to make a recommendation from among the alternatives as well.
7. Close the Issues Log

The project manager documents the resolution or course of action on the Issues Log.
8. Close the Issues Form

The project manager documents the issue resolution on the Issues Form and then closes and files this document.
9. Add action plan to the schedule

Once a resolution is agreed upon, the appropriate corrective activities are added to the schedule to ensure the issue is resolved.
10. Update Charter, if necessary

If the resolution of an issue causes the budget, effort or duration of the project to change, the current Project Charter should be updated.
11. Communicate through the Status Report

The project manager communicates issue status and resolutions to project team members and other appropriate stakeholders through the methods established in the Communication Management Plan, including the project Status Report.

Decide Whether Your Estimate Should Include Client Cost and Effort

noreply@blogger.com (Unknown) — Wed, 30 Apr 2008 06:15:00 -0700

Client effort includes the time to review and approve deliverables, provide requirements, attend meetings, participate in training, etc. Some companies want to understand the total effort and cost of a project, including both the direct project team and the client resource requirements. In other companies, the project costs only include the direct project team. Whether you include client hours and cost in your estimate is an area you should discuss with your manager and your sponsor. If your project estimate includes client hours and cost, the hours need to be kept separately. Although the combined number provides a better overall estimate, the project manager normally is not responsible for the client resources and so he should not be held accountable for achieving those particular targets.

Be Prepared if Others Think Your Estimate is Too High

After you have prepared your estimate, you may need to defend it if the client thinks that the numbers are too high. You should be able to first defend the estimate by explaining the estimating techniques you used, the process you followed and the assumptions you made. If the client still thinks the numbers are too high, or cannot afford the solution at that cost, there are a few options.

* Determine if the client has any additional information that would allow you to revise your assumptions and perhaps revise the estimate. For instance, if a critical end-date now has some flexibility, perhaps the estimate can be revised based on this new information.
* Determine whether high-level requirements and functionality can be scaled back. In many cases, the original set of features and functions is more of a wish list. After seeing a price tag, it is very possible that the client can live without certain features.
* If you included a high contingency to reflect a high estimating risk, ask the client for more time to gather more detail for the estimate. This may result in there being less uncertainty and risk, and allow you to reflect this as a smaller contingency.
* Restructure the project to only include the detailed analysis phase. After the full analysis is completed, re-estimate the remainder of the project, based on a confirmation of exactly what is being requested. The total effort and cost may or may not be lower, but at least you will have more detailed information to back up your estimate.

Back up Your Estimates with a Full Estimating Packet

The next time you are asked to provide an estimate for a major piece of work, consider presenting a packet of information. This does not have to be a thick document; it is only meant to show the rigor that you went through. You should especially consider this if the work is political or if you think that your estimate will not be accepted. Rather than just providing a final estimate, or an estimate range, provide the following information instead.

* Your understanding of the work that was requested
* The process you used to prepare the estimate
* The estimating technique(s) you used
* The actual estimate of the work effort (and duration and cost, if applicable)
* The detailed estimating information in case the sponsor would like to review. For instance, if you did a Work Breakdown Structure, you can include your detailed work estimates
* The assumptions you made in developing the estimate
* The level of uncertainty in the numbers that is reflected in the contingency or the size of the estimating range (more uncertainty is reflected in a wider range)

This would be a powerful packet of information to return to the requestor. If there were disagreements with your estimate, this would give you the facts to respond. It will also stop many challenges because people will have difficulty disputing your facts. You may get asked to change your estimating assumptions or to try another estimating technique. These are legitimate requests and you can re-estimate based on new criteria. But at least the challenges are in terms of the estimating process, not on whether you did a poor job on the estimate itself.

Communication Management Plan Examples

noreply@blogger.com (Unknown) — Mon, 28 Apr 2008 06:41:00 -0700

The following items are examples of the types of communication that could be created as part of an overall Communication Management Plan:

Mandatory

These types of communication are required by your company, your industry or by law. This information is �pushed� (sent directly to) to recipients.

* Project Status Reports
* Regular voicemail updates (of status)
* Status meetings
* Meetings with steering committee
* Regular conference calls and videoconferences with remote stakeholders
* Required reports to shareholders or your Board of Directors
* Government required reports and other information
* Required financial reporting such as budget vs. actuals, budget variances, etc.

Informational

This is information people want to know or that they may need for their jobs. This information is made available for people to read, but requires them to take the initiative, or �pull� the communication.

* Awareness building sessions that people are invited to attend (these are not meant as training � just to build awareness of the project)
* Project deliverables placed in a common repository, directory, website or library that people can access
* Frequently-asked questions

Marketing

These are designed to build buy-in and enthusiasm for the project and the deliverables. This type of communication is �pushed� to the readers.

* Project newsletters with positive marketing spin
* Meeting one-on-one with key stakeholders on an ongoing basis
* Traveling road shows to various locations and departments to explain the project and benefits
* Testimonials from others that describe how the project deliverables provided value
* Contests with simple prizes to build excitement
* Project acronyms and slogans to portray a positive images of the project
* Project countdown-until-live date
* Informal (but purposeful) walking around to initiate discussions about all the good things the project is accomplishing
* Celebrations to bring visibility to the completion of major milestones
* Project memorabilia with project name or image portrayed, such as pins, pencils, Frisbees, cups, T-shirts, etc.
* Publicizing accomplishments

The point of the examples is to show that project communication can take many shapes and forms. For large projects especially, the project team should be creative in determining how, what, to whom, where and how frequently the communication takes place. If the project is controversial, requires culture change or is political, the positive aspects of marketing communication become more and more critical. In these cases, you can also put a proactive plan in place to brand the project with a positive image and feeling.

The Document Life Cycle

noreply@blogger.com (Unknown) — Wed, 16 Apr 2008 07:47:00 -0700

It is important for the project manager to recognize the stages that a document must go through from creation to completion. This knowledge allows the project manager to understand the overall status of a document at any given time and helps ensure adequate time is allocated for the completion of the document. For instance, when a team member says they can complete a document in two weeks, are they saying that the document will be ready to circulate in two weeks or that the document will be completed and totally approved in two weeks? Not all documents need to go through all the stages of document creation and approval. However, depending on the document, one or more of the steps will be required.

Some of the review steps defined here would also be considered part of a quality control process for the documents.

Role

The Document Life Cycle

Plan the document

Sometimes you can sit down and just start writing your document. Other times you need to prepare and plan. This is especially true as your document gets larger and more complex. In many cases you are not able to start writing because you do not have your thoughts structured. Preparation and planning, which includes outlining the content and structuring the sections, will help you get started.

Create the initial document draft

In this step, the document draft is created. If there are no subsequent reviews and approvals, this step results in the creation of the final deliverable. Most of the effort associated with the document is used in this step. Subsequent steps may take a long duration, but they do not take nearly as much effort.

Circulate document for feedback and modify as appropriate

These two steps involve circulating the document for initial review and feedback. The document is updated based on the review comments. Depending on the particular document, this may be an iterative step. A document may have an internal review, followed by a stakeholder review, followed by a management review. After each of these reviews, the document is subsequently modified based in the feedback and sent to the next step.

Gain document approval

When the document has been circulated for feedback and subsequently updated, it will be ready for final approval. Some documents should be formally approved in writing. Others are simply considered complete after the final round of feedback is received.

Like all completed (production) deliverables there may be subsequent updates or enhancements that may require their own mini-document life cycle as well.

Transition Documents to the Right Area After the Project

After the project has completed, some of the documents may be archived, while others need to be maintained indefinitely. For instance, project Status Reports can be archived (or purged) when the project has completed, since they are time-sensitive and have limited value after the project is completed. On the other hand, you should save a User’s Manual after the project is completed. These saved documents can continue to be updated in the document repository if the repository is something that is utilized by the entire organization. Otherwise these long-term documents will need to be moved to the document repository used by the support team.

Some companies maintain a central repository of major project deliverables that can be leveraged for reuse. For instance, the Business Requirements document that was created for your project may be able to be leveraged by another project that is looking into a similar business area. The Testing Strategy your project defined may be able to be reused by another project with similar testing needs. After your project has ended, the project manager and librarian should determine the information that can be leveraged on future projects if the organization has a repository where the documents can be saved.

Five Strategies for the Risk Response

noreply@blogger.com (Unknown) — Thu, 10 Apr 2008 10:36:00 -0700

Use One of Five Strategies for the Risk Response

Once risks have been identified, there are a number of options that the project manager should consider for responses.

* Leave it. In this approach, the project manager looks at the risk and decides to do nothing. This can happen for a couple reasons.

1. The project manager may feel that the risk should be managed, but that the negative impact of the risk is not worth the cost and effort required to manage the risk. In this case you would rather deal with the costs of the risk occurring that the cost of trying to manage the risk.
2. There may not be any reasonable and practical activities available to manage the risk. This is different from the prior reason where the cost was more than the benefit. In this case, there is no practical way to manage the risk, even if the risk has been identified as high. For instance, it is possible that there is a risk of your sponsor leaving and a new sponsor canceling the project. In fact, you may know that the sponsor is up for a promotion and that this scenario has some possibility of occurring. However, you may not be in a position to do much about it as long as the current sponsor is in place, and you may just need to leave it and see how events play out.

* Monitor the risk. In this case, the project manager does not proactively manage the risk, but monitors it to see whether it is more or less likely to occur as time goes on. If it looks more likely to occur, the team must formulate a different response at a later time. This approach can work for serious risks that are not likely to occur. Rather than put a plan in place immediately, the project manager creates a plan only if it looks likely that the risk will occur. The advantage is that scarce resources are expended only on those risks that are likely to occur. The disadvantage is that the delay in addressing the risk might make it less likely that the risk can be successfully managed in the future.

This is also a good approach if you have identified a risk that should be managed, but the risk event is far off in the future. For instance, if your risk event is nine months in the future, it may not make sense to spend resources to manage the risk at this time. A better approach might be to monitor the risk on a monthly basis. It is possible that over time the risk will go away because of other circumstances. However, if it does not go away, the team will still need to manage the risk in the coming months.

* Avoid the risk. Avoiding the risk means that the condition that is causing the problem is eliminated. One example is that if you find that a part of the project has high risk associated with it, that whole part of the project is eliminated. The risks associated with a particular vendor, for instance, might be avoided if another vendor is used instead. This is a very effective way to eliminate risks but obviously can be used only in certain unique circumstances. In another example, you may have a project risk associated with implementing a solution in multiple locations. Once the risk is identified, the sponsor may change the scope of the project to only implement in one location. In this way, the risk of implementing at multiple locations has been avoided.
* Move the risk. In some instances, the responsibility for managing a risk can be removed from the project by assigning the risk to another entity or third party. For instance, outsourcing a function to a third party might eliminate that risk for the project team. The third party might have particular expertise that allows them to do the work without the risk. Even if the risk is still present, it now is up to another party to resolve.

Another example of moving the risk is buying insurance. In a simple example, you may have a very fragile and valuable piece of equipment that needs to be shipped to your project team. There is some risk that the material will be damaged. You might move the financial risk by purchasing insurance on the shipment. Of course, if the shipment is damaged, you may still lose time waiting for a replacement part to be shipped. However, you no longer have the financial risk. In exchange for an insurance premium payment, the insurer now has the financial risk.

* Mitigate the risk. In most cases, this is the approach to take. Mitigating the risk means that you put in place a set of proactive steps to ensure that the risk does not occur, or that the impact of the risk event in minimized. Both are valid mitigation strategies. (For the purposes of the TenStep Project Management Process, it is generally assumed that Risk Management Plans are put in place to mitigate the risk.)

noreply@blogger.com (Anonymous) — Wed, 26 Mar 2008 08:39:00 -0700

Managing Outsourced Projects

Outsourcing of project work is more common today than ever. However, even though you outsource the work, you cannot completely outsource your obligation to make sure the project is progressing smoothly. If all goes well with the outsourcer, you do not have much work to do. Unfortunately, in many instances, the outsourcing vendor does not perform against expectations. If that happens, you want to know about it as soon as possible. For the purposes of this discussion, let us assume that your company has outsourced a project, or a portion of a project. Your company has also asked you to manage the relationship to ensure the vendor performs as expected.

Many people are not sure what they should be doing when they are asked to manage an outsourcing relationship. Part of the uncertainty is because some of the project roles are reversed when you outsource work to a third-party. On a normal internal project, the project manager assigns the work and manages issues, scope, risk, quality, etc. The project manager makes sure work is done on time and the project is progressing as it should. He is held accountable for the success of the project. Other people perform a quality assurance role to make sure things are progressing as they should.

With an outsourced project, the vendor takes on the direct management of the outsourced work. The client project manager is now the one that has to ask the quality assurance questions to make sure the vendor project is progressing as it should. Some of the up-front questions to ask include:

*

Is there a contractual agreement that spells out the expectations of both parties in terms of deliverables to be produced, deadlines, payment schedule, completeness and correctness criteria, etc?
*

Has a comprehensive project schedule been created?
*

What is the Project Management Plan the vendor will use to control the project?
*

Has the vendor been clear on what resources will be needed from your company and when they will be needed?
*

Have a number of agreed-upon milestones been established to review progress so far and validate that the project is on-track for completion?

Ongoing Questions

As the project is progressing, you must continue to ask questions to determine the current state of the work. You may have status meetings weekly, but there should be a formal quality assurance check at the end of every agreed-upon milestone. The types of questions you would ask at every milestone include:

*

Have the deliverables specified in the Project Charter been completed up to this point?
*

Have the appropriate deliverables been agreed to and approved by the company?
*

If the vendor has met expectations up to this point, have any interim payments been released?
*

Can the vendor clearly explain where the project is vs. where it should be at this time?
*

Will all the future deliverables specified in the Project Charter be completed?
*

Are issues, scope, and risks being managed as stated in the Project Management Plan?
*

Should the contract or Project Charter be updated to reflect any major changes to the project?

Once you understand your role on the project, it is easier to ask the right questions to make sure that everything is progressing as it should.

The Discovery Project

noreply@blogger.com (Anonymous) — Wed, 5 Mar 2008 07:16:00 -0800

For large projects, there is a tendency for the project definition process to become very lengthy and unfocused. Defining the work for very large projects takes enough time that it should be structured as a project itself. This is the purpose of defining a separate Discovery Project.

This should make sense. If the project is ultimately going to take 50,000 effort hours, it may take a number of months to get the project defined and approved. In these cases, a distinct first project is established to define the second larger project itself. The final deliverable for a Discovery Project is a completed Project Charter, Project Management Plan and project schedule for the subsequent large project. For the most part, all the other deliverables will be produced as a part of the next follow-up project.

The Discovery Project should be planned and managed as a project. This includes defining the work, building a schedule and budget and subsequently managing the Discovery Project. You want to make sure you are clear on what is expected at the conclusion of a Discovery Project.

Discovery Projects, like all projects, come in all sizes. You should estimate the effort and duration required for the Discovery Project. Based on the effort required for the Discovery Project, you can categorize the Discovery Project itself as small / medium / large. Remember that this is the relative size of the Discovery Project, not the final project. Depending on the size of the Discovery Project, you again have three options on how to define the work.

For a small Discovery Project, a service request can be created to define the work. Even thought he Discovery Project is small, you can assume that the final project deliverable will be a full Project Charter and a project schedule for the subsequent project.

For a medium-sized Discovery Project, you should follow the TenStep Project Management Processes for defining and managing a medium project. The Discovery Project should have an Abbreviated Project Charter and project schedule, and be managed just like any other medium-size project, including managing issues, scope, risk, etc. When the Discovery Project is complete, the Project Charter, Project Management Plan and project schedule for the subsequent project should be created. The approval process for these documents should be a part of the Discovery Project. Assuming that the Project Charter is approved, the subsequent larger project can start at any time. However, the TenStep steps 1.0 Define the Work and 2.0 Build the Schedule and Budget will already be completed. (These planning processes were the purpose of the Discovery Project). The project management process for this subsequent project can begin in Step 3.0 Manage the Schedule and Budget.

If the size of your Discovery Project is, in fact, a large project itself, you should follow the steps required for defining large projects. You would want a full Project Charter to define the Discovery Project, and you would want a full project schedule, budget and Project Management Plan. If the Discovery Project is a large project, the subsequent project will generally be huge - perhaps a program of related projects. Similar to a medium project, the Discovery Project would create the Project Charter, schedule, budget and Project Management Plan for the subsequent larger project (or program). Assuming that the Project Charter is approved, the subsequent larger project can start after the Discovery Project is completed.

Manage Documents on Projects

noreply@blogger.com (Anonymous) — Wed, 27 Feb 2008 04:06:00 -0800

Project and Project Management Documents

The document repository holds all the project deliverables - both project-related and project management-related. For instance, the repository will hold the Project Charter and project schedule (project management deliverables), as well as the Technical Design and Testing Plan (project deliverables). When you start to consider your document management process, all of the documents your project produces must be taken into account.

Document Workareas

Usually the document repository does not hold documents that are currently being worked on (this may also depend on any document management software being used). Each team member should have a workarea where he or she can store versions of documents that are currently in-progress but not yet in circulation. This can be a directory structure or a folder that each team member has full access to. Team members can structure their work area in whatever way makes sense to them.

Draft Copies

Draft copies are documents that have been initially completed by the author, but are not yet ready to be considered entirely complete from a project perspective. In most cases, this is because the document is in some kind of review process. Draft copies of documents could be stored in the author's workarea. However, for large projects, or ones where more rigor in document management is needed, it will make sense to maintain a library or folder for draft copies. In this case, the update process would look as follows:

1.

A document is created and edited in the author's workarea.
2.

After the initial draft is completed, the document is moved from the workarea to the draft library. The document stays there until the author needs to update it or it is ready to be moved to the repository as an approved document.
3.

When the document is in the draft library, it can be circulated for review and input.
4.

If the draft copy needs to be updated again, the document is copied back to the workarea for updating, leaving a copy in the draft library.
5.

This process is repeated until the document is totally complete. Then the document can be moved from the draft library to its final location in the document repository.

The value in this approach is that the project team always has one official draft of each document and only one live, approved version as well.

Garbage in – Garbage Out

This classic problem still exists in document management no matter how sophisticated your processes become. Document management helps you store and retrieve information that already exists in the project. However, even if you find the document, the content may or may not be helpful. Team members need to understand that their documents must be well-written so that others can read them and understand the content. On some projects, team members search for documents, find them, but then discover that the content in them is unusable. Your document management processes may help in these situations by getting others, including the librarian, involved in reviewing documents before they are added to the repository. However if you allow poorly-written documents to be added to the repository, you may find that people are not going to utilize the repository as often since they will not perceive value in the documents that the repository contains.

Document Management Technology Will Influence Your Process

Much of the process for managing documents is influenced by any document management technology used on the project. For instance, document management software will usually come with a standard logical structure. You just plug in your specific names to make it real. Software may also enforce versioning and have features for controlling update authority. The tool may also describe the metadata needed for keywords and indexing.

Calculating the Critical Path

noreply@blogger.com (Anonymous) — Wed, 20 Feb 2008 12:38:00 -0800

ES – Early Start

EF – Early Finish

LS – Late Start

LF - Late Finish

There is a manual method for calculating the critical path. This involves looking at the earliest start date (ES) and earliest finish dates (EF) for every activity starting at the beginning of a project and moving to the end of the project. You then start at the end of the project and go backward, looking at the latest possible start dates (LS) and latest finish dates (LF) for every activity. The difference between the latest start day and the earliest start day for each activity is the activity float (this will end up being the same as the difference between the latest end day and the earliest end day). You then look for the sequence of activities from start to end that have zero float. This is the critical path.

1.The forward pass involves starting at the first activity in the network diagram and calculating the earliest that every activity can start (ES) and the earliest every activity can finish (EF).

2. Once the final activity is scheduled using the forward pass, you start at the end and work backward. The backward pass involves calculating the latest that every activity can finish (LF) and the latest every activity can start (ES), while still completing the project on time.

3.The critical path contains activities that all have zero slack.

The Critical Path May Change

There are many sequences of activities on a project to get from the beginning to the end. There may, in fact, be multiple critical paths, if they all have no float and all lead to the same end-date. Usually if there are multiple critical paths, they overlap for many of their activities

Given that there are many, many paths through the workplan, it's possible for the critical path to change. For instance, say you have the same example as above, with 22 activities over nine months. Let's assume that there is another path of work that includes 19 activities and takes 8 1/2 months. If you tried to accelerate the schedule to complete the project in eight months, it gets a little complicated. First you would want to focus on accelerating the activities in the nine month critical path. However, once the critical path is reduced to 8 1/2 months, this second critical path emerges that has the same overall timeline. Compressing the original critical path further will not make the project end earlier, because this second path is still going to take 8 1/2 months to complete. In this case, both paths must be accelerated (or perhaps some activities that are common to both can be accelerated).

The other way the path may change is if activities off the critical path get delayed. In the example above, let's say that one of the activities on the 8 1/2 month path ends up taking an extra three weeks. Because there was only two weeks of float in the path, it will now become the critical path and force the entire project to complete one week late.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Defining Scope

noreply@blogger.com (Anonymous) — Wed, 13 Feb 2008 09:05:00 -0800

Defining Scope

Defining scope is perhaps the most important part of the upfront definition and planning process. If you don't know for sure what you are delivering and what the boundaries of the project are, you have no chance for success. If you have not done a good job of defining scope, managing scope will be almost impossible.

The purpose of defining scope is to clearly describe and gain agreement on the logical boundaries of your project. Scope statements are used to define what is within the boundaries of the project and what is outside those boundaries. The more aspects of scope you can identify, the better off your project will be. The following types of information can be helpful in defining scope.

*

The deliverables that are in scope and out of scope. You should definitely include deliverables in your scope statements. However, only describe your final deliverables and the project deliverable that are client-focused. For instance, the Business Requirements Report and Current State Assessment could be listed as project deliverables since they are both client-approved deliverables. You would not need to mention internal project documents such as the project workplan, Technical Design or Test Cases.
*

The major lifecycle processes that are in scope and out of scope. For instance, your project may include the Analysis Phase only and not the Design, Construct or Test Phases.
*

The types of data that are in scope and out of scope. Data types refer to financial data, sales data, employee data, etc. It is possible that your project works with some types of data and does not work with others.
*

The data sources (or databases) that are in scope and out of scope. This is similar to the data types, except now you are referring to aggregated data, such as Customer Database, General Ledger, Billing / Invoicing System, etc. (These data sources may have more than one data type.)
*

The organizations that are in scope and out of scope. In some cases, the organizations involved in the project help to define the boundaries. For instance, your project may focus on Human Resources and Accounting, but the Manufacturing Division might be out of scope.
*

The major functionality that is in scope and out of scope. For instance, decision support and management reporting might be in scope, while overnight batch processing might be out of scope.

Use High-Level Objectives as Your Starting Point

When the project was proposed for funding, there should have been an initial set of high-level objectives and deliverables defined. Any information that was created earlier should be used as the starting point for defining the more detailed scope statements for the Project Charter. If you find that you do not have enough information to create a clear and comprehensive scope statement, you must work with the sponsor to gather additional information. That is one of the main purposes of the definition and planning process.

If you have project objectives, look at them to help shape the scope statements. By definition, there needs to be one or more deliverables created to fulfill each objective, and defining the project deliverables is one of the primary aspects of project scope. After you determine the major deliverables the project will produce, start asking other questions to determine other aspects of scope. The deliverables describe 'what' the project will deliver. You can also identify 'what' organizations are impacted, 'what' types of data are needed, 'what' major features and functions are needed, etc.

As a point of clarity and contrast, you can also identify out-of-scope conditions by describing what deliverables will not be created, what organizations will not be impacted, what features and functions are not included, etc. Of course, there are an infinite number of out-of-scope statements. For the purposes of scope definition, you want to include only those statements that help define the project boundary and touch upon related areas that the reader may have questions about. For instance, if you were installing financial software, you might state that a new Accounts Payable package is in scope, but the related Purchasing System is out of scope. This would make sense because the Purchasing and Accounts Payable processes are related and there may be questions as to whether the Purchasing System was in scope. However, you would not have to list every other system as out of scope � just the ones that the reader might have questions about.

It is a good practice to document those organizations that are in scope and those related organizations that are out of scope. The readers can then determine more easily if they are impacted or expected to assist in the project. Also, it may make sense to identify the organizations that are in scope so that you can have people from those organizations represented on the project team - perhaps on a steering committee.

Aligning Objectives and Scope

When you have completed creating your objectives and scope statements, go back and make sure that they are all in alignment. You should not have any objectives that make references to deliverables that are not defined in your scope statements. Likewise, you don't want to include deliverables in your project scope that do not help to achieve the project objectives. If the two areas are not in full agreement, either the scope or the objectives (or both) must be modified to bring everything into alignment.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Goals and Objectives

noreply@blogger.com (Anonymous) — Thu, 7 Feb 2008 08:59:00 -0800

Goals are high-level statements that provide overall context for what your organization is trying to achieve in the next three years. Objectives are lower level statements that describe the specific, tangible products and deliverables that the project will deliver. The definition of goals and objectives is more of an art than a science and it can be difficult to define them and align them correctly. However, through practice and the use of some common definitions, you can start to identify and tell the difference between goals and objectives.

Business Goals

Goals are high-level statements that describe what your organization is trying to achieve over a one to three year horizon. For example one of the goals of the IT Support group might be to "increase the overall satisfaction levels for clients calling to the company helpdesk".

Because the goal is at a high-level, it may take more than one project to achieve. In the above example, for instance, there may be a technology component to increasing client satisfaction. There may also be new procedures, new training classes, reorganization of the helpdesk department and modification of the company rewards system. It may take many projects over a long period of time to achieve the goal.

The goal should reference the business benefit in terms of cost, speed and / or quality. In this example, the focus is on quality of service. Even if the project is not directly in support of the business, there should be an indirect tie. For instance, an IT infrastructure project to install new web servers may ultimately allow faster client response, better performance or some other business benefit. If there is no business value to the project, the project should not be started.

If you can measure the achievement of your goal, it is probably written at too low a level and is more of an objective.

If your goal is not achievable through any combination of projects, it is probably written at too high a level. In the above example, you could envision one or more projects that could end up achieving a higher level of client satisfaction. A goal statement that says you are trying to achieve a perfect client experience is not possible with any combination of projects. It may instead be a vision statement, which is a higher level statement showing direction and aspiration, but which may never actually be achieved.

Project Objectives

Objectives are concrete statements that describe the things the project is trying to achieve. An objective should be written at a lower level, so that it can be evaluated at the conclusion of a project to see whether it was achieved. Goal statements are designed to be vague. A well-worded objective will be Specific, Measurable, Attainable/Achievable, Realistic and Time-bound (SMART). (However, SMART is a technique for wording the objective. An objective does not absolutely have to be SMART to be valid.)

An example of an objective statement might be to "upgrade the helpdesk telephone system by December 31 to achieve average client wait times of no more than two minutes".

*

Note that the objective is much more concrete and specific than the goal statement.
*

The objective is measurable in terms of the average client wait times the new phone system is trying to achieve.
*

You can assume that the objective is achievable and realistic.
*

The objective is time-bound, and should be completed by December 31.

Objectives should refer to the deliverables of the project. In this case, the objective refers to the upgrade of the telephone system. If you cannot determine the deliverables that are created to achieve the objective, the objective may be written at too high a level. On the other hand, if an objective describes the characteristics of the deliverables, it is written at too low a level. If the statements describe the features and functions, they are requirements, not objectives.

Importance of Objectives

Objectives are important because they show a consensus of agreement between the project manager and the project sponsor on the main purpose of the project. The specific deliverables of an IT project, for instance, may or may not make sense to the project sponsor. However, the objectives should be written in a way that they are understandable by all of the project stakeholders.

Define Objectives Before the Project Starts

The project objectives and the business goals they support should be defined and agreed upon before the project starts. The deliverables of the project are created based on the objectives - not the other way around. That is, you don't agree on the deliverables first and then establish objectives to match. You must understand the objectives of a project and then determine what deliverables are needed to achieve them.

A facilitated meeting between all major stakeholders is a good way to create the objectives and gain a consensus on them at the same time.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

TenStep Project Management Tip of the Week

noreply@blogger.com (Anonymous) — Wed, 23 Jan 2008 03:59:00 -0800

Hold Everyone Accountable for Scope Management Process

Many scope management processes work well at the project manager level, but get compromised by team members. If the project manager is diligent in enforcing the scope change rules, the client may try to go directly to team members for changes. For instance, when an agreed-upon report is delivered for review, the client may request a second report to provide more clarity. The team member may agree to the work (showing 'client focus'). The result is that the activity takes too long or resources that could have been applied to other high priority work get absorbed working in an area that is out of scope.

The bottom line is that everyone needs to be held accountable for the scope management process. Team members must understand the process and why it is important. The client must also understand the process and its importance. Don't consider these procedures to be only of interest to the project manager and the sponsor. Make sure the procedures are communicated to the entire team.

When clients request scope changes directly from team members, bring this to the attention of the client manager or the sponsor. When team members make commitments for work that is out of scope, deal with it promptly. The first time it happens it may be considered a training matter. The next time it might be a performance problem.

The Change Control Board

Sometimes on very large projects, the project sponsor does not feel comfortable making the scope change decisions alone. This may especially be the case if the effect of the change will impact other organizations. It may also be the case that multiple organizations are participating in, or contributing to, the project funding, and want to have some say in evaluating scope change requests. For these cases, a group of people might be needed to handle the scope change approval.

A common name for this group is a Change Control Board. If a Board exists, it may be more cumbersome to work through. However, the general scope change management process does not need to change dramatically. For instance, there is still a document for the initial the scope change request. The project team needs to determine the impact and cost to the project. The Board must consider the impact, the value to the project, the timing, etc., and then make a determination as to whether the request is accepted.

The Scope Change Procedures must be somewhat more sophisticated to account for the Board. For instance, you need to clarify who is on the Board, how often they will meet, how they will be notified in emergencies, how they will reach decisions (consensus, majority, unanimous, etc.), how incremental work will be paid for, etc.

Only the Sponsor Can Approve Changes – Not Users and Client Managers

A typical problem on a project is that the team does not understand the roles of the sponsor, client and end users. In general, the project sponsor is the person who is funding the project. If the client were embodied in one person, it would be the project sponsor. The sponsor is usually high up in the organization and not easy to see on a day-to-day basis. In most cases, the sponsor designates someone in his or her organization to make most decisions on a daily basis.

The people that the project team tends to work with most often are end users. End users are the people that use the solution that the project is building. The end users are the ones that will generally make requests for changes to deliverables. It doesn't matter how important a change is to an end user, the end users cannot make scope change decisions and they cannot give your team the approval to make a scope change. In proper scope change management, the sponsor must give the approval. The end users can request scope changes, but they cannot approve them. The end user cannot allocate additional funding to cover the changes and they cannot know if the project impact is acceptable. If the change is important enough to the Sponsor, he or she will approve it, along with the appropriate budget and duration changes. If the change is not important enough, it will not be approved. However, it will be the Sponsor making the decision, not the project manager, client manager, project team or end users.

Five Steps for Updating Your Resume

noreply@blogger.com (Anonymous) — Tue, 22 Jan 2008 17:49:00 -0800

Five Steps for Updating Your Resume
Caroline Levchuck, Yahoo! HotJobs

It's a new year! And while you may not need an entirely new resume, you should probably freshen up your current credentials.

Updating your resume doesn't have to be too time-consuming or painful, says resume expert Lauren Milligan, founder of ResuMAYDAY, a Chicago-based resume writing and career services firm. She shares five quick tips for breathing new life into your old resume.

1. Start at the End

Don't overwhelm yourself by looking at your entire resume -- yet. "Look at the bottom of your resume and see if there's anything new that you can add. Workshops, professional training, or awards are a quick way to add something current," says Milligan.

2. Where You've Been and Where You're Going

Next, look at the position nearest the bottom of your resume. Milligan advises, "Ask yourself if it's still relevant to your current career goal. If it's not, delete it so you can build on more current accomplishments that will further your career."

If that last position is still somewhat relevant, "Just edit it down. The very first position you held should get the least amount of attention," she reveals.

3. A Year in the Life

Turn your attention toward your current job. Milligan says, "Update any new projects or accomplishments that have occurred over the last year. Even if it's not a promotion, just include anything from 2007 that can be added to it."

4. Update Your Look

Current information deserves a current look. Does your resume look stylish and polished -- or plain, dull, and dated? If so, Milligan believes it may be time to give your resume a face lift. "If you're still using the same resume format you used a few years ago, you should change it to something more suited to the positions you're currently pursuing -- not those you had after graduation."

Also, make your resume available in several formats -- text only, Microsoft Word, and a PDF. "There's a good use for each of these formats. Having a PDF of your resume at the ready implies a little more technical savvy on your part."

5. Proofread. Proofread. Proofread.

Milligan cannot stress enough the importance of proofreading your resume. "Every time you make any changes to your resume, it's possible to introduce another error," says the resume and careers guru. "Proofread it again and again, and ask a few friends to look at it, also. You can never be too careful."

Adds Milligan, "If you have a 'blah' resume, you're leaving yourself open to those jobs that other aren't willing to do. Update it to make it great!"

Projects / Products- TenStep Project Management Tip of the Week

noreply@blogger.com (Anonymous) — Wed, 2 Jan 2008 05:33:00 -0800

Projects vs. Products

Projects are the way that most new work gets delivered. All projects have certain characteristics in common.

*They all have a beginning and an end.
*All projects are unique. They may be similar to prior projects but they are unique in terms of timeframes, resources, business environment, etc.
*Projects result in the creation of one or more deliverables.
*Projects also have assigned resources - either full-time, part-time or both.

There are other characteristics as well.

Projects can be managed using a common set of project management processes. In fact, a similar set of project management processes can be utilized regardless of the type of project. For instance, all projects should be defined and planned, and all projects should have processes to manage scope, risk, quality, status, etc.

Products on the other hand, are tangible items that are produced by a project, or perhaps purchased from a vendor. (The vendor would have created the initial product through a project.) Project management can be thought of as a process. A product is delivered by a project. �Product management� is an approach for centrally coordinating the activities surrounding the long-term support and enhancement of a product. The person that executes these responsibilities is called a Product Manager.

The product management process can start during the project that created the product. If you purchased the product, the product management process can begin when the product is purchased, or a little earlier in the product evaluation and selection process.

Product Management

The role of a project manager is to plan and manage a project. The role of a product manager is focused on the long-term support of the product within the organization. The product management role includes the following responsibilities.

*Product Planning
o Coordinate product issues and all communication as the primary contact with the product vendor
o Monitor product direction with the vendor and communicate this information to company stakeholders
o Determine which components of the product should be used in the organization
o Identify opportunities for use of the product
* Testing
o Coordinate testing of new products and releases, including coordinating pilots with potential product users
o Determine when a product is �production-ready� based on testing and pilot projects
o Coordinate certification of new products and releases
* Financial Management
o Coordinate negotiation of product contracts, purchase agreements, and maintenance agreements
o Ensure that budget is available for product purchases and maintenance
o Determine when to consider canceling or reducing maintenance payments based on product direction
* Product Implementation and Deployment
o Coordinate development of a product deployment plan
o Manage and monitor the deployment of the product or new releases
o Deploy (distribute) the product
o Track product inventory (where the product has been deployed)
o Receive ongoing requests from the staff for individual product deployment
o Integrate and add new products and releases into the architecture
* Product Release Management
o Decide when to upgrade to a new release
o Plan and manage new release implementation
o Ensure new releases get added into the architecture if required
* Product Retirement
o Determine when product needs to be retired
o Plan and manage product retirement
o Retire (uninstall) the product from the environment
o Ensure product gets removed from the architecture

Manage Human Resources - TenStep Project Management Tip of the Week

noreply@blogger.com (Unknown) — Wed, 19 Dec 2007 17:52:00 -0800

The Client May Not Know Enough to Completely Define the Project

Sometimes the project manager places too high an expectation on the amount of foresight and vision that clients have. In many cases, the project manager will go to the client looking for answers to help define the project and the client will not have all of the information needed. This happens all the time and it does not mean that the client does not know what they are doing. In many cases, especially for large projects, the client has a vision of what the end results will be, but cannot yet articulate this vision into concrete deliverables. They may also not know all of the answers on scope, risks, project organization, etc.

Based on having less than complete information, the project manager may feel the need to guess on the details. This is not a good solution. It is better to state up-front everything that you know, as well as everything that you do not know. If you are asked to come up with estimated effort, cost and duration, you will need to provide a high and low range based on the uncertainty remaining.

Another good alternative is simply to break the work down into a series of smaller projects (as described previously). Even if the final results cannot be clearly defined, there should be some amount of work that is well defined, which will, in turn lead to the information needed for the final solution. You should only define a project to cover as far as you can comfortably "see" today. Then define and plan subsequent projects to cover the remaining work as more details are known. For instance, you could create a project that gathered business requirements, and then use the results of that project to define a second project to build the final deliverables.

If you are not allowed to break the project into smaller pieces, you should at least know enough that you can plan the work for the first 90 days. In this third approach, you plan the short-term work in more detail, and leave the longer term effort more undefined. Each month you should redefine and plan the remaining work. As you uncover more and more information, you can plan the remaining work at a more detailed level. As you uncover more details, you can refine your estimates and work with the sponsor to make sure it is still okay to continue.

Try to Understand Your Client's Expressed Needs and Their Real Needs

The Project Definition describes the project at a high level. The Project Definition specifically describes the needs of the client, as well as the project team's estimate of the effort, duration and cost to fulfill those needs. The details of the client's need are then defined in more detail through the gathering of business requirements.

It is important for the project manager and project team to understand that the true needs of the client may or may not be the same as the needs that are expressed to you and that are the foundation of the Project Definition and the business requirements. In many cases, the client does not understand their true needs when the project starts. The true needs can sometimes evolve over the course of the project. Likewise, the client may have a clear vision of their needs, but they may have a hard time expressing the needs to the project team. To a certain extent, this is the purpose of scope change management - to allow the client to change the requirements of the project while it is in-progress.

The project team can do nothing better than to document the expressed needs of the client and use the expressed needs as the basis for the approval of the Project Definition and the Business Requirements. However, it is also true that the project team should do as good a job as possible uncovering the true needs of the client. This involves techniques such as asking good questions, asking targeted follow-up questions, gathering input from all key stakeholders, asking more questions when requirements don't seem to make sense, etc. Obviously, the project team should do whatever they can to try to uncover the true needs of the client. The closer the true needs of the client are to their expressed needs, the closer you will be to getting the project right the first time.

How Silicon Valley Says 'Sorry'

noreply@blogger.com (Anonymous) — Fri, 14 Dec 2007 10:46:00 -0800

by Andy Greenberg

Forget about gleaning leadership lessons from the likes of Attila the Hun or Alexander the Great. These days, great chief executives have to know when to retreat and when to say "I'm sorry."

Technology executives in particular had plenty to apologize for this past year--from defective products to slip-ups in how they handled private data collected via the Internet. Most recently, chipmaker AMD CEO Hector Ruiz apologized to Wall Street on Thursday for fumbling the company's high-end product line after a design flaw delayed its newest chip. (See: " AMD Comes Clean To Analysts")

In fact, apologizing has become such a standard operating practice among Silicon Valley's chief executives that public relations gurus have developed some "best practices" for all that begging and scraping.

In Pictures: A Brief History Of Tech Executive Apologies

"You have to act like a leader," says Torod Neptune, crisis management leader at tech-focused PR firm Waggener Edstrom. "Get out ahead of something and manage it before it becomes a crisis. If you act quickly enough, an apology can even make your brand stronger."

Facebook's 23-year-old founder, Mark Zuckerberg, got his lesson in humility just last month. At the beginning of November, Zuckerberg declared Beacon, a new advertising program on Facebook, to be nothing less than the greatest media revolution in the last hundred years. Only four weeks later, Beacon's privacy violations had throne it into a PR tailspin. In the face of protests by more than 70,000 of Facebook's users, Zuckerberg announced new controls on the advertising program, and he apologized.

"We simply did a bad job with this release, and I apologize for it," Zuckerberg wrote in his blog.

Considering Zuckerberg's original cheerleading, that concession may seem like the ultimate humiliation. But it was the right move, say the experts.

"He wins points for being humble and accountable," says Chris Gidez, director of crisis communications at PR firm Hill & Knowlton.

"Very straightforward," says Karen Doyne, a crisis PR consultant at Burston Marsteller.

"You'll never please everybody," says Torod Neptune, crisis management leader at Waggener Edstrom. "But he seems to have nipped it in the bud."

When Zuckerberg's apology surfaced, the protest's 70,000 or so privacy advocates still represented a relatively small seed of revolt--less than .2% of Facebook's 50 million plus members. Facebook's apology and changes to Beacon seem to have appeased that angry minority before it could swallow up the site.

That such a small group could pull a contrite message out of a chief executive also shows just how the Web can channel consumers' anger. And tech companies may be especially prone to those backlashes: Not only are tech customers particularly Web savvy, but the tech industry itself frequently sails into uncharted and--from a PR perspective--dangerous waters, says Waggener Edstrom's Neptune.

"The tech world is focused on innovation," says Neptune, whose clients include Microsoft (nasdaq: MSFT - news - people ). "Where CEOs are having a hard time is where that innovation runs counter to users' attitudes, especially in the world of new media and social media."

Those collisions lead to PR crises, and not every tech companies has handled them as cleanly as Facebook, Neptune points out. Back in 1994, for instance, Intel (nasdaq: INTC - news - people ) CEO Andy Grove was far less wary of the Internet's ability to bring a chief executive to his knees.

When customers learned about a flaw in Intel's Pentium chips, Grove refused to acknowledge the bug. By his engineers' calculations, the flaw would actually manifest itself just once in thousands of years of use. But when a report of the Pentium flaw made its way on to an early Internet newsgroup, users erupted. Grove dragged his feet, but as the protests mounted, he issued a reluctant apology and a warranty for the chips. That fumbled crisis was the worst mistake in Grove's career, according to biographer Richard Tedlow.

Much more recently, Yahoo! (nasdaq: YHOO - news - people ) CEO Jerry Yang, has become a textbook case of how not to apologize, Waggener Edstrom's Neptune says. In 2004, the Chinese government demanded the e-mail records of Chinese journalist Shi Tao from Yahoo! China. The company provided them, and Shi Tao was arrested and sentenced to 10 years in prison. Human rights groups accused Yahoo! of being the puppet of an authoritarian government. Yahoo! argued that it had little control over Yahoo! China, a portion of the Chinese Web company Alibaba partially owned by Yahoo!

Those arguments fell flat, however, when Yahoo!'s Chief Executive Jerry Yang was hauled in front of the House of Representatives Committee on Foreign Affairs in October. The Committee's Chairman, Representative Tom Lantos, lambasted Yang and Yahoo!'s general counsel Michael Callahan, calling them "moral pygmies." Yang himself squirmed uncomfortably and then apologized sheepishly to the jailed journalist's mother, who sat behind him.

"A lot of us watched that hearing and were stunned at how unprepared Yahoo! was," says Neptune. "They really didn't seem ready to apologize publicly like that."

By contrast, Apple (nasdaq: AAPL - news - people ) Chief Executive Steve Jobs caught on quickly when his company was confronted by angry consumers in September. Just two months after diehard fans had waited in line for hours to buy the newly released iPhone, Apple had slashed the price by $200. Hundreds of enraged e-mails poured in from customers who felt snookered by the original $600 price. Jobs apologized within just 24 hours, offering those customers a $100 coupon at Apple stores.

"He gets very good marks for that," says Randy Pitzer, a technology public relations specialist with Edelman. "Essentially he turned a crisis into an opportunity to bring more customers into Apple's stores."

Jobs' real insight, says Pitzer, was understanding just how willing his customers would be to forgive him. He points to an Edelman survey done early this year of more than 3,000 people who ranked technology at the top of a list of "most trusted" industries, ahead of businesses like banking, telecommunications and health care. "A lot of technology companies don't realize that they have a bit of leeway," he says. "There's a kind of built-in trust factor, and when executives don't realize that, they don't leverage it." And most important, Pitzer says, Jobs didn't wait to say: "I'm sorry."

In fact, Jobs' apologetic skills come from practice. Despite his reputation for stubbornness, Apple's chief apology officer has staged two other turn-arounds in the recent past. In May, Jobs caved to Greenpeace's demands that Apple become more transparent about its use of toxic minerals and apologized to customers for "keeping them in the dark." And in October of last year, he expressed his regret to Apple's shareholders and employees for the company's stock options back-dating.

The lesson from all that grovelling? Apologizing pays.

Top 10 access-related controls for PCI compliance

noreply@blogger.com (Unknown) — Thu, 13 Dec 2007 10:31:00 -0800

By Robert Westervelt

The Payment Card Industry Data Security Standard (PCI DSS) is a set of minimum security guidelines put in place to protect sensitive credit card data. But the standard outlines some of the most vital technologies and access-related policies and procedures needed to determine who has what and who did what on your systems, according to Viresh Garg, a member of Oracle's enterprise manager team and Oracle identity and compliance initiatives.

In a recent presentation conducted at Oracle OpenWorld last month in San Francisco, Garg outlined the top 10 access-related controls for PCI compliance and described why they are important in locking down data and keeping out intruders. Companies that have the tools to ensure continuous monitoring, identify, report and investigate audit trails and conduct risk analytics are taking the right steps to protect critical data, Garg said.

# Data cleanup: Detect and remediate rogue accounts and grants. An effective security plan begins with data cleansing, Garg said. Access and identity related data must be cleansed to avoid duplicate information, wipe out terminated employees and start with a clean slate.
# Access control policies: Define policies and procedures and ensure that they apply to applications and the data center. This can often be a difficult area to tackle, Garg said. Business and IT roles need to be determined as well as the roles of all end users to define who has access to certain applications and the kind of authority they have to make changes to those applications.
# Access control processes: Review accounts and privileges and discover who has been given approval to access sensitive information or conduct certain business processes.
# Physical security: Investigate and determine the company's access badge procedures. Integrate the procedures into the overall security guidelines.
# Password management: Identify the current password procedures and possibly deploy a single sign-on technology. Develop a password plan that makes it easier for users to remember their passwords so they avoid writing them down.
# Risk-based adaptive authentication: Two-factor authentication should be in place. It forces end users to provide two means of identification, one of which is typically a physical token, such as a card, and the other of which is typically something memorized, such as a security code. This helps block access from potential intruders and notifies administrators of the potential of fraudulent activity, Garg said.
# Audit trails: By collecting and keeping accurate audit trails, companies gain a big benefit by allowing an investigator the ability to capture a point-in-time snapshot of system activity, Garg said. For example, an administrator could look at who had access to an application a year ago to determine the source of suspected fraudulent activity.
# Reports: By keeping reports of system logs and reviewing those logs, companies can reduce risk to acceptable levels, Garg said.
# Attestation: Much like the attestation used to comply with the Sarbanes Oxley Act, attestation is used to meet PCI access control standards by forcing a periodic review of user access rights. Companies can set up an automated review process to enable the right managers to certify or reject the access rights of employees in their unit. This keeps access data clean and eliminates duplicate and outdated information.
# Risk analysis: Similar to deploying a business intelligence solution for financials, deploy a tool to analyze the audit trails that were developed. Find weaknesses in critical infrastructure and applications.

Be Careful of What You Dream

noreply@blogger.com (Unknown) — Wed, 12 Dec 2007 16:50:00 -0800

By Keith A. Shaw

"Be careful of what you dream, because it may come true."

My high-school football coach, Coach "Pic," would tell us this every day in his motivational speech as we prepared for the upcoming game. His goal was to get each of us to create a mental picture of what we wanted to do -- individually and as a team.

So, here are three strategies that I have used successfully and that you can utilize to achieve your dreams as well...

Number 1 – Write your dreams down on paper.

There are numerous studies that prove the value of writing down and keeping track of your thoughts and goals. A study sponsored by the Ford Foundation found that:

* 23% of the population has no idea what they want from life, and as a result, they do not have much.

* 67% of the population has a general idea of what they want, but they do not have any plans for how to get it.

* Only 10% of the population has specific, well-defined goals, but even then, seven out of the ten of those people reach their goals only half the time.

* The top 3%, however, achieved their goals 89% of the time.

What accounted for the dramatic difference between the top 3% and the others? The top 3% wrote down their goals, their dreams, their THOUGHTS. Simply put, dreams are not goals until they are written on paper. They become a road map for you to follow.

Number 2 – "Pre-set" your mental state for the next day before you head off to bed.

Here's my secret. Before my head hits the pillow, I spend about five to ten minutes in quiet reflection and thought as to what I want my next day to be like. I think about the things that I want to achieve, such as a financial goal, spiritual strength, courage, or other goals, and let my subconscious "dream-mind" work on these while I sleep. I have learned from experience that this strategy not only works in the short term to solve an immediate problem, but also helps me to come up with solutions to achieve a longer-term goal.

Number 3 – Review your list of dreams and do not be discouraged when you are "off course."

When you focus your mind on your dreams and goals, you centralize your attention, just like you focus a camera lens on the subject of your photograph. Be sure to monitor and check yourself from time to time. People who do not follow the practice of honest self-evaluation can never identify when they are getting off course.

For example, before an airplane takes off and flies from one city to another, the crew maps out a flight path. Along the way, they must account for headwinds, tailwinds, turbulence, weather issues, and more that cause the plane to drift off course. Now, do the pilots panic? No! They read and analyze the plane's telemetry and systematically make the adjustments needed to get the passengers to the destination. Systematic and ongoing self-evaluation will allow you to do the same by reading your "telemetry" and keeping you on your "flight plan" so that you successfully reach your destination.

Eleanor Roosevelt said, "The future belongs to those who believe in the beauty of their dreams."

Design the future of your dreams. And be careful, they may come true!

C Stands for Different

noreply@blogger.com (Unknown) — Wed, 12 Dec 2007 16:48:00 -0800

By Lynn M. Scheurell

By Webster's Dictionary definition, a catalyst is something that provokes significant action. That's what I do -- I provoke my clients to think and act differently in their lives for greater fulfillment. After all, we have to do different to get different.

It is my intention that you find something thought-provoking enough to do something different in your own life.

Connection
Connection happens on two levels. First is connection with the self in an essential sense of center that's unshakable by external events. The second is connection with others for community.

Creativity
When creativity is open, it's delicious to explore the unseen -- what's around your next corner. By being curious, receptive, and initiating questions or actions, you can play with infinite possibilities.

Clarity
By reducing the "noise" in your head, your being, thinking, and doing become crystallized. Decisions are easier, right action is smoother, communications and relationships are cleaner -- and your calendar becomes focused.

Considerations
Life is full of considerations, some of which are necessary. However, it is important to recognize which are real. It is important to not tolerate the unnecessary. Compromise only when it's meaningful.

Courage
There are times when situations require us to confront things that make us uncomfortable or even afraid. Until we pass through it, we do not learn our lessons. Having the courage to face it gives us the ability to move forward.

Confidence
When you are comfortable in who you are, you naturally make choices that support your knowingness and demonstrate trust in who/where you are. It's a powerful magnet to attracting more of what you want.

Contribution
It is in giving that we grow, by sharing what we have that we increase our own capacities. Giving back where we can creates good karma.

Collaboration
Building by partnership/teamwork creates a synergy that otherwise wouldn't exist. When two or more people are gathered in focus, great things are created and achieved.

Celebration
Honoring what has happened in celebration feels good. It is a timeless ritual to acknowledge hard work and mark a milestone or an ending. Without celebration, we may not know that we are moving into a new beginning.

Circle Back
Review the lessons learned to see if you've missed anything, or if you can use something previously discarded in a new way. Circling back allows you to express appreciation for both the people who have been touched by your learning journey and your progress.

Compassion
Through compassion for others, we acknowledge our oneness. While we are all at different places on our respective journeys, the destination is the same.

Conviction
As long as you are in alignment with your higher self, believing in what you know to be true for you is the backbone to good decisions, personal leadership, accountability, and good health.

Communication
Speak your truth clearly, concisely, and honestly. You can avoid about 80% of problems with other people by having good communication skills. You can resolve 100% of your personal challenges by being honest with yourself.

Control
Control means doing what you can and releasing whatever you just did; it has to go do/be whatever you have given it life to do. Control is a superficial illusion, attempting to force situations, people, or things to fit -- it's like trying to push a river. Being in flow means recognizing that there is no control.

Common Sense
Maybe this should be "un"-common sense... common sense comes from everyday living. If something makes sense to you, do it. However, just because somebody else does it a certain way doesn't mean that it makes the best sense for you.

If any one of these resonated with you on some level, that's an indicator of where you can start in doing something different. If more than one hit a nerve, start with the first one.

You will notice that people and situations around you will change -- be alert. Watch for synchronicities and pay attention to how you feel -- that's the best measure of your success in being different.

Empowerment Changes Your Life Forever

noreply@blogger.com (Unknown) — Wed, 12 Dec 2007 16:46:00 -0800

By Lisa Whatley

Perhaps you are asking, "What is personal empowerment?"

Put in simplistic terms, empowerment is freeing yourself from limitations or living a life of misery and taking full responsibility for everything that is in your life. It's about quitting making excuses for things that aren't going right in your life and DOING something about changing them! It's about choices, the choices that you make on a daily basis regarding all aspects of your life. It's about being in control of what you allow in your life, who you associate with, what you read, what you watch on television and at the movies, who your mentors are, what music you listen to, what you eat, etc. Why are these choices so important to empowerment? ... You literally ARE your choices.

A general definition: empowerment is a process that helps people gain control over their own lives.

Therefore, empowerment is about learning there are choices, in which you have the right to be the healthiest and happiest person you can be in this now. The past is the past, and it cannot be changed; therefore, the focus is placed upon what you can do in this very moment. What choices can you make to empower yourself NOW? As you exercise your choices and take responsibility and action, you will gain increased control over your life. I had a million excuses for everything crummy in my life. I even blamed my addictions to cigarettes, drugs, and alcohol on other people. I blamed everyone for everything because that enabled me to justify in my own mind that it was O.K. I was slowly killing myself to avoid having to face my problems, the exact problems that I was creating by the choices that I was making. It's a vicious cycle, but empowerment can change it!

Let's take a look at a list of empowerment key words:

* Self-Mastery
* Personal Development
* Positive Thinking
* Mind Power
* Self-Improvement
* Spiritual Growth
* Enlightenment
* Responsibility
* Law of Attraction
* Self-Power
* Self-Acceptance
* Self-Reliance
* Self-Esteem
* Self-Discovery
* Self-Strength
* Self-Love
* Self-Confidence
* Self-Control
* Own Choice
* Independence
* Own Decision Making
* Being Free
* Awakening
* Capability
* Choices
* Power Into Action

This is a small list, but as you can see, it's a list that outlines qualities that cannot be found outside of ourselves because empowerment comes from within. I was looking outside of myself. That is where I went wrong and where millions of others are going wrong too. When we activate this power within ourselves, we have the strength and courage to make choices and act on issues that we define as important. These issues can relate to any and all areas of our life: relationship, financial, personal, spiritual, and physical. It's very important to understand that empowerment is a multidimensional process which includes all levels of our being: mental, emotional, physical, and spiritual, and each of these areas must be brought into balance.

The empowerment process may be facilitated and supported through outside sources such as utilizing the assistance of a person specializing in life coaching, learning energy healing and mind techniques, attending self-help groups and seminars, home study programs, reading books, etc. It is very important that these programs teach you and give you the skills on how to do these things independently for yourself after the program has been completed. You are looking for independence, not codependency within the system, because empowerment is a process that develops as we work through it. It is impossible to dabble in empowerment, expecting life-changing results. It must become a path, journey, lifestyle, or way of life for complete liberation of all pain and suffering.

I have a "rags to riches" true-life story. I learned how to overcome poverty, addictions, and abuse to create the life that I once thought was completely impossible for me to have. I have beaten the odds because I dared to believe and listen ONLY TO MYSELF, which IS the power within! Guess what I have accomplished since I learnt the secret of self-mastery and empowerment? I'm now a successful entrepreneur, a published writer, an international life coach, energy healer, and empowerment specialist. Not too bad for a once "high-school dropout, sexually and physically abused, druggie, alcoholic, welfare case," huh? That's what empowerment is! It's about making choices that improve the quality of your life.

With empowerment comes wisdom, and by wisdom I do not mean knowledge of facts so much as the ability to perceive and understand facts, and to judge soundly and act right in all matters relating to life. Wisdom is the power to perceive truth and the ability to make the best use of the knowledge of truth.

With wisdom comes poise and the power to think right, to control and guide your thoughts, and to avoid the difficulties which come from wrong thinking. With wisdom you will be able to select the right courses for your particular needs, and to guide yourself in all ways as to secure the best results.

The beauty of empowerment is the ripple effect. Through personal empowerment, you have the potential through leading by example to teach those around you to empower themselves as well! You not only manage to change yourself, but also contribute to changing the lives of your children, family, and friends. You have the ability to break the chain of poverty, addictions, abuse, and suffering within your own family. You are able to show them that where you once were powerless, you were able to gain full control over your life, improving your situation by taking full responsibility and action over your own mastery. This will show them that it can be done because YOU did it! You lead by example, and your children are only learning and repeating what you teach them. Lead them into empowerment.

So what can be more empowering than gaining control over self? I invite you to start today, right NOW!

Crucial Elements For Jumping Sales Numbers

noreply@blogger.com (Unknown) — Wed, 12 Dec 2007 16:42:00 -0800

By Allyn Cutts**

Marketers from every niche have common ground when it comes to bills. Yeah, every month there’s a new stack of bills demanding to be paid. Will there be enough profit to slide right through bill paying time without a flinch? Or do you find yourself fretting about whether you’ll even break even? You don’t have to be victimized by envelopes and 8x10 sheets of paper. Implement these 3 techniques to boost your sales.

1. Find More Customers
The first thing that comes to mind when we think of making more money is getting more customers through our doors. In fact, the majority of advertising focuses on doing just that. There are several things you can do to entice more customers to buy from you.

Implement Follow-Ups
Marketing gurus have discovered that follow ups can increase your customer conversion rates by as much as 50%. Now, that’s a whopping improvement! Don’t let potential customers fade away. Keep the doors for future communication open, and watch the drastic growth in your profits.

Encourage Referrals
Every satisfied customer will tell 3 friends or family members about your business - without encouragement. Imagine what would happen if you start rewarding their efforts.

Get Free Publicity
Nearly everyone keeps a sharp eye on the local news. Hey, it’s funner to know what’s going on when you personally recognize the names and faces in print! Find ways to make your business newsworthy and catch the attention of potential customers without even paying advertising fees.

2. Sell More Per Customer
Think about it... how can you get every customer that walks through your doors to spend more money before walking back out the doors? Here are 3 sure-fire, profit increasing tips:

Increase your prices.
Hey, that might not be as bad as you think. Along with the price increase, focus on increasing the perceived value of your product. Yeah, we all expect to pay a little more for high quality stuff. Not everyone is bent on finding the absolute cheapest price in town... they may be more interested in lasting quality.

Add some higher end products or services to your business.
It’s never wise to put all of your eggs in one basket. That’s why wise marketers diversify their products and services. Think of it this way... higher priced products may not make as many sales, but each sale will bring in a much greater profit. You don’t need to make as many sales to come out on the best end of the deal.

Upsell
Offer every customer an additional product that accents his current purchase at the register. Hey, maybe they forgot they’d need batteries to go with the toy they're getting for their niece's birthday gift! You can be a hero... a richer hero.

3. Sell More Often
The fact that it’s easier to sell to the people who know and trust you is obvious. Sometimes we get so focused on new customers that we miss the gold mine in our own back yard. Take advantage of the hard work you’ve invested in winning the loyal customers you already have with these ideas:

Create a Special Deal
Show your customers you appreciate them and understand their needs with a special offer catered just for them. You’ll be thanking them, and selling more in the process.

Add New Products
Increase the number of products you already have available - especially products that your customers have asked for. They’ll know that you’re looking out for them, and you’ll take their thanks to the bank.

Communicate
Resell yourself on a regular basis. Don’t forget to let them know about upcoming specials that they’ll appreciate. Most of all... keep selling them on the benefits of the products or services you offer.