Your Organization Culture Influences Project Success
It should come as no shock to learn that some organizations are better than others at managing projects. There are probably no organizations that have a 100% success rate, and hopefully none have a 0% success rate. However, some organizations definitely perform at a higher level than others.
There are a number of organizational factors that influence your ability to deliver projects successfully. Your organization’s culture has a lot to do with the success rate of your projects.
The term “culture” generally means “how we do things around here.” For example, if someone asked how well your organization's delivers projects, you might say “we are pretty weak at delivering projects on time and on budget”. If so, you are expressing your perception about your project delivery culture.
There are a number of areas where culture comes into play on projects.
- Process orientation. Many organizations have good processes in place, and people generally follow them. This is perhaps the biggest single factor in overall project success. If your organization follows a good, scalable project management process, you are more likely to be consistently successful on your projects. This means that the entire project team generally knows how to create and follow a realistic schedule and can use standard processes to effectively handle risk, scope change and issues.
- Governance. Many organizations have processes in place, but no one follows them. This is a problem with management governance. In simplistic terms, governance is the management function having to do with making sure people do what they are supposed to do. Typically, if your management structure is engaged and interested in projects, and if they make sure that your project management process is followed, you will tend to be more successful. If every project manager is on his or her own and management support is haphazard, you will tend to be less than successful.
- Training. Some organizations do a poor job of training project managers. (Typically, these types of organizations do a poor job of training in general.) If project managers generally do not have the right skills (other than from the school of hard knocks) you will not be as successful as you like.
- Sponsor engagement. In successful organizations, people typically know the role they play on projects and what is expected of them. This especially includes active and engaged sponsors. Sponsors need to provide guidance, monitor the project, remove barriers, approve major deliverables, and more. If your organization leaves project managers in a leadership vacuum without strong sponsor support, you are not going to be consistently successful.
Should You Factor Positive Risk into Project Planning?
Risks represent potential future events or circumstances that could have an impact on your project. Generally we think of risk having a negative impact. However, what if the impact on your project was positive? In that case you would have an opportunity risk.
You have heard the saying that you should "push the envelop", "be a risk-taker", or at least that you should take "intelligent risks". These statements get to a difference between how risk is typically identified from a project management perspective. Positive risk refers to risk that we initiate ourselves because we see a potential opportunity.
For example, let's say that you have a project that is scheduled to take 12 month to complete. Your sponsor would like the project completed earlier. One of your team members has an idea. If you utilize a new engineering process, it is possible that you can deliver the project in nine months. If this were a guaranteed solution, you would jump on it. However, there is risk since it is the first time you have used the process. There is a lack of expertise and a start-up learning curve. It is possible that if the process does not work out, the project could end up taking 15 months to deliver. What would you do?
This example illustrates the concept of opportunity risk. If you decide to use the new process, it is a risk you are introducing yourself, based on an evaluation of the chances of success, and the impact of success, versus the chances of failure and the impact of that failure. When we say we are intelligent risk-takers, it is these types of decisions that are being evaluated.
There are a number of ways to respond to positive risk.
- Accept. Do nothing and hope that the benefit of the positive risk occurs.
- Exploit. Remove the uncertainty of the risk and try to make certain that the event will occur.
- Share. Share the risk with another party that is better able to capture the benefit associated with the risk.
- Enhance. Look for ways to increase the probability that the risk occurs, or increase the size of the benefit if the risk event occurs.
Five Advanced Document Management for Large Projects
Document management is a process for managing how you plan, store and retrieve documents on a project. Managing documentation is usually a part of the broader communication management process. Most projects don't need to worry about formal document management processes. However, if your project produces a lot of documents you should think ahead of time about how you will store them so that they are easy to find later.
Of course you should think about naming standards, directory structure and common document formats. In addition, large projects should also consider the following.
- Assign a document librarian. The responsibilities of the librarian are as follows:
- Coordinate activity that is related to the document repository
- Establish, maintain, and enforce document repository standards and monitor them for conformance
- Identify and resolve repository problems
- Monitor and control access and updates to the repository
- Define access rules. The access rules describe items such as who can review documents and who can update them. Most documents should be accessible for the entire team to read. Some documents may need to be more secure. However, you should also be clear on the documents that team members can access and update.
- Define repository update procedures. All team members will need full access to their own documents. However, the project manager needs to decide whether anyone can make updates to other team member’s documents as well. For instance, some documents might be open for anyone to update. Others need to be locked down to prevent updating without proper authority.
- Determine retention and purging timeframes. Purging old documents ensures that the information on the repository is relevant. For instance, weekly individual Status Reports may not be needed after three months. On the other hand, the Project Charter document is needed for the life of the project.
- Hold periodic repository review. If your document repository is very complicated, it may make sense to perform a periodic review of the repository and the overall document management processes. The librarian will be responsible for coordinating this review.
Use These Nine Elements to Complete a Statement of Work
Partnering with high performing suppliers can be critical to delivering successful projects. Whether you're hiring a supplier to deliver equipment, provide consultancy or simply make the coffee—the key is to document your requirements for their delivery upfront within a "Statement of Work" (SOW). Without a detailed SOW) it will be difficult to manage your suppliers performance, as you will not have a clearly laid out set of requirements upon which to base their performance.
(Note that some organizations use an SOW on internal projects - often as another name for a Charter. However, I am using the term now as a procurement document - that is, between a buyer and a seller.)
Although you may have a formal supplier contract in place, the contract will most likely specify the legal aspects of the relationship - not the specific procurement requirements of your project in detail. The SOW is used to:
Creating a detailed Statement of Work is not too difficult a task. Complete the following steps to create a comprehensive SOW for your project.
1. Background. Describe any perspective or background information that makes sense for the project. For instance, you may wish only to work with suppliers over a certain company size, with experience providing certain types of products and a detailed knowledge of your industry and local market. You may also require that the supplier has a certain number of years experience and clients who can to act as referees.
2. Deliverables. Provide a detailed description of the deliverables and or services to be provided by the supplier. For each product, describe in detail its components (if a 'good') as well as any skill-sets required (if a 'service').
3. Dates. Clearly state the dates within which deliverables must be complete, and any other expectations for the deliverables or services.
4. Training. Identify the training required by your project team, if any, to ensure that maximum benefits are gained from the goods and services provided by the supplier.
5. Documentation. List any documentation to be supplied, such as an Operating Manual, User Guide, Business Processes or Support Procedures.
6. Support. Describe the level of support required of the supplier by specifying thing like the support hours needed and the level of support to be given.
7. Other materials. Include any other materials and equipment to be provided by the supplier to the project team.
8. Acceptance. Describe the process for acceptance of each deliverable, to ensure that deliverables are formally reviewed and accepted by the project team before they are deemed 'complete'.
9. Payment terms. Identify the conditions and terms for making payment to a supplier for goods and services rendered.
That's it. If you complete each of the steps listed above, you will create a comprehensive Statement of Work which can be used to get the most out of your supplier relationship.
Describe Project Value Using a Business Case
It can be hard to compare and prioritize the projects in your portfolio because there are many different types of projects. Some projects might increase revenue, some might decrease costs and some might help build internal capability. All of them have some benefit but it may not be easy to know which ones are the most valuable and which ones are the most aligned to your goals and strategies.
The way that you compare projects is through a common Business Case. The Business Case describes the reasons and the justification for the project. It also contains high-level information on the project, including estimated costs, risks, deliverables, assumptions, and the expected business benefits and value. The sponsor is responsible for the Business Case.
Business Cases should contain the following information:
- Description of the project. This is a description of what is being proposed. Be sure that it provides enough information so that others can understand the work that is being proposed.
- Assumptions. List the circumstances or events that must occur for the project to be successful. Assumptions are the things that are considered to be true even though they are not 100% facts. There is some uncertainty, but the Business Case “assumes” certain things to be true for the purpose of planning and definition.
- Risks. List the circumstances or events that would be a major impediment to the success of the project. Risks have a probability of occurring, but they are not guaranteed to occur. Risks generally are seen as bad things that have a detrimental impact on the project.
- Financial model. Your organization must create the common financial model for all projects (ROI, EVA, etc.). This is extremely important if you are going to compare projects on an apples-to-apples basis.
- Estimated business benefit. You must try to determine tangible and intangible benefits in terms of your common financial model. Some business benefit may be indirect, but the benefits should be as tangible as possible to compare favorable with other projects.
- Estimated cost. Provide as accurate estimate of the cost as possible. Your department may set a standard for the level of accuracy required. For the Business Case, you might look for estimated cost to be within 35%-50%.
- Alignment. Validate the alignment by specifying how this work contributes to your organization's goals and strategies. Your organization should have a pre-defined model and common rating scheme for alignment so that you can compare projects effectively.
- Is the work required? Specify whether you feel this work is essential. Some work may be required for legal or regulatory reasons, even if it is not aligned and does not have obvious business benefit.
- Urgency. Describe the required timing of the project. Some projects need to start at a certain time. Some projects must be completed by a certain time. Other projects can be executed at any time throughout the coming year.
- Consequence of not performing this year. Describe what the consequences are of not performing the work. In many cases, this is just as important to know as the business benefit and alignment.