Building Blocks of a Successful Project Part 1 – Business Sponsorship

Initiation

The “Building Blocks” series of posts will help you identify key prerequisites that must be in place before you begin your project. Whether you are the Project Manager from the start of the project, or taking over someone else’s already started project, make sure these Critical Success Factors are in place.

There are certain fundamentals that need to be in place to increase the probability of project success. The first of these is to have an active and committed Business Sponsor. The Business Sponsor is the person (or persons) who initiated the project and authored the Business Case. The primary roles of the Business Sponsor are to provide funding, help clear obstacles to success, provide resources and make key decisions.

It is surprising how many projects (IT projects especially) proceed without this key building block. The thinking is that the merit of the project itself will drive it to successful conclusion. This is a huge mistake. Projects like this will typically encounter a lack of cooperation from the business units as their priorities do not match the priorities of those driving the project. It is OK for IT to get the ball rolling, but before the project is officially approved, the Business Sponsor must be identified and take ownership.

The Business Sponsor will play a key role in your Organizational Change Management Plan. Their responsibilities will include:

  • Being the “Face” of the project communicating directly with employees and management
  • Participating actively and visibly throughout the project
  • Building a coalition of sponsorship and manage resistance – identify other Executives who will Champion the change
Advertisements

Requirements Analysis Using Event Response and Use Cases: Overview

Initiation

This is the start of a multi-part series on my favorite requirements elicitation technique: the Business Event/Response Analysis. Early versions of this methodology were developed in the late 1980’s by some of the great system development minds of that era. Since then it has evolved and I have adapted it to meet the needs of whatever organization for which I am working.

There are some that think you can gather requirements by just asking the sponsors and users “what do you want?”. Needless to say, this method will generate incomplete requirements and tends to start and end with functional requirements. In the latter half of the project when large requirements gaps are discovered, the sponsors/users blame the analyst and vice versa.

When I teach on this topic, I tell the analysts it is their responsibility to gather complete requirements. Given this, we need a method that will (1) generate the appropriate questions to ask, (2) ensure that we have the complete set of requirements, and (3) allow us to derive the functional requirements from the model.

The Business Event/Response method meets these desired outcomes. The advantages are:

  • It helps the Business Analyst create the questions needed to draw the requirements from the Business Owner, even if the Analyst has no knowledge of the business area.
  • It organizes the requirements in the context of Business Processes and Usage to promote better understanding.
  • The output serves as a starting point for defining the testing scope and scenarios.

In the upcoming posts I will describe this method in detail.

The Project Charter – Sign Off

 

Initiation

The Project Charter can be looked at as a contract between you and your project sponsor or you and your manager. It documents your understanding of the expectations of the sponsor and what you are expected to deliver and when. Like any contract, it should be concluded with a signature indicating agreement.

Why get a real signature? It is amazing how people will pay close attention to what is in a document when they have to sign their name to it! I have seen cases on my own projects as well as those I consulted on where misunderstandings are cleared up prior to charter sign off. This has and will save many hours of effort avoiding taking a project down the wrong path. For these reasons I highly recommend getting a real signature and posting a PDF image of the Project Charter in the project repository.

Once you have a signed-off charter, you now have one of the deliverables subject to formal Change Management. Any request that would change any component of the charter should have a formal change benefit/impact statement signed off and the Project Charter should be changed to a new version and signed off again.

In my next post we will move to the Planning Phase and begin a multi-part discussion on the Project Management Plan.

The Project Charter – Constraints

Initiation

Constraints are any limitations to solution options that have been imposed on a project. It is important to know these early on so time is not wasted pursuing these options. Here are some examples:

  • The solution must work with Microsoft Internet Explorer 8 as that is the company standard
  • The solution must be an Oracle product for seamless integration with our other Enterprise systems
  • The new department we are adding as a result of this project must fit into this 30′ x 50′ area

When project constraints are uncovered, be sure to understand the reason why. It is possible some constraints could be removed. I was involved with a project where the service provider was already selected but without looking at the competition. I convinced my business partners to conduct formal “Request for Proposal’s” with the leading competition and the result was a different provider was selected.

Constraints are included in the Project Charter so that the Sponsor and Core Project Team understand and agree.

The Project Charter – Issues

Initiation

Issues are any event or known problem that will negatively impact your project’s schedule, scope, budget or quality. Issues differ from Risks in that Issues are 100% will or has happened whereas Risks may or may not happen with a probability less than 100% and greater than 0%. Risks that are not actively managed are more likely to become Issues.

At Project Charter time, you want to highlight the most severe impacting issues. Look specifically for the impacts in the following areas:

  • Schedule – issues that will delay your project start, or impact key milestones and the target completion date.
  • Scope – Issues that can prevent you from delivering the defined project scope
  • Budget – Issues that can cause the project to go over the allowed budget
  • Quality – Issues that will affect the quality of the delivered solution

In a subsequent post I will address Issue Management in detail.

The Project Charter – Risks & Assumptions

Initiation

In upcoming posts I will discuss Risk Identification and Management in detail. For now, you just need to know that a risk is an uncertain future event that can have a negative impact on your project’s schedule, scope, budget or quality. The event has a probability of occurring less than 100% and greater than 0%. If the probability is 100%, then you have an issue, not a risk. Some risks can have a positive impact but we will not discuss that here.

You state the risk as follows:

  • If <risk event> occurs, then <state the outcome that affects your project> causing the project  to be impacted in the following specific ways <scope, schedule, budget, quality>.

At the Project Charter level, you are interested in identifying only the highest impact risks so that your risk management strategies can be accounted for in the scope and schedule.

Some Project Charters will list “Assumptions” in its own section. I have eliminated assumptions from my own charter template as I feel if you have assumptions that can impact your project, then that is just another form of risk. I now include any assumptions in my risk section.

The Project Charter – Stakeholders

Initiation

Project Stakeholders are the people and entities affected or impacted in any way by the project. Defining this list is critical in communication planning. It will also help you in defining the project scope. Stakeholders are identified by reviewing the Project Scope and consulting with Subject Matter Experts for the domain of the project.

There are two classifications of Stakeholders:

  1. Those that will be needed to perform project tasks.
  2. Those that will interact with or receive the product, service or result of the project.

The Stakeholders in classification 1 are the members of your project team. Some of these will constitute your core team and will be needed full-time or near full-time for the duration of the project. Others will be needed only for specific tasks over limited periods of time. When you have this list I recommend creating a spreadsheet with these names along with their roles, responsibilities, manager, and contact information.

The Stakeholders in classification 2 are your project’s “customers”. These are the people who will be the target of a formal Change Management strategy (more on that in upcoming posts). The success of your project will often depend on how you manage communication and change with this group of Stakeholders. The five key areas for managing this group of Stakeholders are:

  1. Awareness – communicate early and often with this group before they are impacted
  2. Desire – impart an understanding of why this is good for them and for the company
  3. Knowledge – training in new processes and behaviors
  4. Ability – make them successful by setting up a support structure
  5. Reinforcement – monitoring the expected behaviors and business outcomes and being prepared to make adjustments as new knowledge comes to light

There are some Stakeholders that can be a member of both groups. Typically members of the Project Sponsor’s team will participate in the project and also be affected by the result.