Strategizing Project Delivery
Posted by Brad EgelandThe purpose of strategy is to provide direction and concentration of effort as organizations continually strive to improve their position or gain the upper hand within the marketplace. Basically, it’s a struggle for advantage, and the one with the best advantage wins. It’s that simple. On what areas must businesses concentrate? Businesses clearly have to:
- Gain new advantages that increase or improve customer satisfaction, which will differentiate them from their competitors
- Either eliminate or minimize their competitors
- Achieve speed to market
- Re-engineer business processes for improved competitiveness
- Align their organizations to the latest economic trends
- Implement the strategy through projects
- Evaluate the success of the strategy by measuring project success
From project management’s point of view, there is no need to manage any project if the project manager has no idea why it’s being done in the first place. It’s crucial for any project manager to address the larger issues of the business strategy and see where the project fits in the overall framework. It isn’t easy—but it needs to be done.
Therefore, organizations must focus on project management as the key business driver that will achieve these advantages for them. With sound project management methodology and processes in place, project management is able to support the overall business strategy of an organization with these logical benefits:
1. Reduced delivery costs. Project management can provide products and services more cheaply by following a structured and formalized project methodology and by ensuring that excessive costs are not spent without due consideration.
2. Quicker product to market. The advantage permits the business to deliver products or services more efficiently than the competitors and the business is able to react more favorably to market demands.
3. Focused advantage. The projects will be focused more on the client needs and products, instead of having a solution that does not deliver the expected returns.
4. Quality and timely deliverables. Project management builds quality into the products or services right from the start, ensuring that the right things are developed at the right specification.
5. Proven customer advantage. Project management gains advantages for their organization by working together with the customer and by accommodating their needs and requirements.
Summary
Today’s organizations are challenged, as they need to keep pace with competitive markets, client needs, and marketplace trends. Winning is basically about who has the upper hand – either with new technology or quicker project implementations. The only winners will be those executives who are able to reinvent their companies quickly enough to take full advantage of the efficiencies that solid project management practices can offer.
Defining Implementation Success or Failure
Posted by Brad EgelandSometimes indentifying whether your project or implementation was a success or failure is not as straightforward as just looking at the metrics involved with project management. It’s not always about on time and on budget. And it may not entirely be about customer satisfaction either.
In Henry Lucas’ book “Information Technology for Management” he defines first what an Implementation is and then looks at some of the possible criteria for determing that implementation’s relative success or failure factors.
What Is Implementation?
Implementation is part of the process of designing a system and is a component of change. We develop a new information system to change existing information processing procedures and often to change the organization itself. Implementation refers to the design team’s strategy and actions for seeing that a system is successful and makes a contribution to the organization.
Our definition stresses the long-term nature of implementation. It is part of a process that begins with the very first idea for a system and the changes it will bring. Implementation terminates when the system is successfully integrated withthe operations of the organization. We expect most of implementation to be concerned with behavioral phenomena since people are expected to change their information processing activities. Implementation becomes more important and difficult as systems design becomes more radical. If a firm undertakes a maj or reengineering project, it should make major changes in tasks to reduce costs and improve productivity in the organization.
Success or Failure
How do we know that we have successfully implemented a system? Researchers do not agree on an absolute indicator for successful implementation. One appealing approach is a cost/benefit study. In this evaluation, one totals the costs of developing a system and compares them with the dollar benefits resulting from the system.
In theory, this sounds like a good indicator of success, but in practice it is difficult to provide meaningful estimates. Obtaining the cost side of the ratio is not too much of a problem if adequate records are kept during system development. However, an evaluation of the benefits of an information system has eluded most analysts. There are a number of categories into which we might classify the benefits or value provided by an application of technology. These categories include:
- Infrastructure
- Required applications
- Applications where technology was the only solution
- Applications providing a direct return
- Applications with indirect returns
- Technology initiatives that are a competitive necessity
- Strategic applications
- Transformational information technology
For only a few of these categories are we likely to be able to demonstrate a direct financial return, which makes it difficult to perform a cost/benefit analysis to determine the “success” of a system.
As an alternative, we can choose among several indicators of successful implementation for an individual application, depending on the type of system involved. In many instances, use of a system is voluntary. A manager or other user receives a report but does not have to use the information on it or even read the report. Systems that provide interactive retrieval of information from a database also can often be classified as voluntary. The use of such a system is frequently at the discretion of the user. A manager with a personal computer in his or her office is not required to use it. For the type of system in which use is voluntary, we shall adopt high levels of use as a sign of successful implementation. We can measure use by interviews with users, through questionnaires, or in some instances, by building a monitor into the system to record actual use.
For systems whose use is mandatory, such as a production control system or a computer that provides stock market quotations for a broker, we shall employ the user’s evaluation of the system as a measure of success. For example, onecan examine user satisfaction, although it will probably be necessary to measure several facets of satisfaction, such as quality of service, timeliness and accuracy of information, and quality of the schedule for operations. An evaluation might also involve a panel of information processing experts reviewing the design and operation of the system. We should also note that managers might well consider a system to be successful if it accomplishes its objectives. However, to accomplish its objectives, a system must be used. We would also hope that one objective of a system would be extensive use and a high degree of user satisfaction.
Finally, though it is difficult to do, we can try to estimate the impact of a system on individuals and the organization. How has a system affected personal productivity and output quality? Can the organization point to added sales or increased revenues from a competitive application? Can we show that IT has had an impact on performance, either for individuals or the organization?
The Project Disaster Recovery Plan
Posted by Brad EgelandFrom my experience, it’s not often that you’ll put together a Disaster Recovery Plan that is project-specific. The exceptions are government projects – which sometimes require separate one-time documents for the project for which you charge dearly to put them together – and larger, very visible and mission critical projects that may involve highly sensitive data.
However, if you find yourself up against a wall and facing a deadling to put a DRP together, maybe this template will be just what you need. As with all the others I’ve posted over the past few days, if you want a Word doc version of this template, let me know and I’ll be happy to send it out to you. And, if you have your own version that you’d like to see posted and share with the readers here on PM Tips, send it along to me and I’ll see that it gets posted.
Disaster Recovery Plan
1.0 Preliminary Planning
This part of the plan describes the purpose, scope, assumptions, responsibilities, and overall strategy relative to the plan.
1.1 Purpose
Describe the reason and objectives for having a DRP.
1.2 Scope
Describe the extent of the coverage of the plan in concise terms.
1.3 Assumptions
A DRP is based on several categories of assumptions. Most can be established only after the completion of a risk assessment that includes the following information:
- Nature of the problem
- Priorities
- Commitments to or Assumptions of Support
1.4 Responsibilities
Document the specific responsibilities as assigned by management to all activities and personnel associated with the plan.
1.5 Strategy
The selection of appropriate strategies should follow the risk assessment. Until the risk assessment is completed, it is difficult to know the critical systems that must be maintained, and the demand for resources that will be made to support those critical systems.
1.5.1 Emergency Response
The strategies selected must provide a sufficient base upon which procedures can be devised which afford all personnel the immediate capability to effectively respond to emergency situations where life and property have been, or may be, threatened or harmed.
1.5.2 Backup Operations
Most backup sites will not have sufficient equipment, personnel, supplies, etc., to sustain the complete operational requirements or another facility. In this case, a more detailed backup strategy must be developed.
1.5.3 Post-Disaster Recovery Actions
The strategy for recovery must be linked closely with that of backup operations, as initiation of recovery actions may overlap.
1.6 Record of Changes
Each DRP should be preceded by a change audit record that lists all changes to this document, including the change number, change date, change detail, person making the change, and the date that the document is published.
1.7 Security of the Plan
This plan should be available to just those personnel affected by the plan.
2.0 Preparatory Actions
This part of the plan is key. Preparatory actions are critical to the emergency response, backup, and recovery from all but the most routine problems.
2.1 People
Provide names, addresses, and telephone numbers of all people, internal and external (vendors and/or contractors) who may be required in any backup or recovery scenario. Alternates should be designated.
2.2 Data
It is essential that all data on which backup and recovery are dependent be adequately recorded, stored offsite at a secure, environmentally safe facility, maintained in as current condition as is feasible, and occasionally tested to ensure validity.
2.3 Software
It is also essential that a current copy of the systems and application software programs be stored offsite at a secure, environmentally safe facility that will make that software available immediately.
2.4 Hardware
A DRP should minimize, to the greatest feasible extent, the dependence on rapid replacement of hardware. Define a list of the hardware and where replacements are available. Identify any contracts in place to ensure the availability of any hardware.
2.5 Communications
Define both the internal (LAN) and external (WAN) communications connectivity.
2.6 Supplies
Describe any special supplies that are needed.
2.7 Backup Site
Describe the location of the backup facility. When choosing a backup site, consideration should be given to accessibility, and the site should be free of whatever external problems are hampering the supported facility.
2.8 Space
Describe the physical location where the recovery operations will take place.
2.9 Power and Environmental Controls
Define the power and environmental controls that are required for the recovery.
2.10 Documentation
Describe all backup documentation that is kept in the offsite facility.
3.0 Action Plan
This part of the plan consists of the “what to” actions to be accomplished by those personnel or activities identified in section 1.4, and should only consist of concise, short instructions of the specific actions to take in response to each of the categories below:
3.1 Emergency Response
Include the immediate actions to be taken to protect life and property, and to minimize the impact of the emergency.
3.2 Backup Operations
Describe what must be done to initiate and effect backup operations.
3.3 Recovery Actions
These should be limited to describing what to do in effecting recovery from disasters, including any alternate manual scenarios until the systems have been restored at the backup site.
4.0 Post-Disaster Review
Immediately after the resumption of the IT function, IT management should assess the success and adequacy of the plan, and update the plan accordingly.
Approved:
__________________________________________
Business Sponsor
__________________________________________
IT Director
__________________________________________
Development Director
__________________________________________
Infrastructure Director
The Project Change Order Request – Version 2
Posted by Brad EgelandAs promised – another version of the love-hate Change Order Request. This is a cut/paste from a Word doc template that I would be happy to share. The Word doc version looks much better, but this at least gives you an idea of the content that is being captured here for customer approval.
The main concept is to capture as much information about the proposed scope change as possible and estimate each task effort that it’s going to take to get there. Once that effort and budget info is captured here, that information can easily be rolled into the project schedule to show your customer how the change order request is going to affect the overall project timeline.
I’ve been using this version – or at least some variation of it – for most of the past three years on projects and it’s served me very well. The change order request is always a delicate subject for both the project manager and the customer so handling it carefully and in the greatest detail possible is critical to good decision-making and for on-going customer satisfaction since it usually results in the customer paying more on the project (but not always because even things that decrease the project scope and cost should be documented using this same process….it affects the project, too!).
Again, if you want a Word doc version of the template let me know. And if you have a version you can share, I’d like to see it and share it with our PM Tips readers as well.
Change Request Initiation |
|||
|
Change Title |
|
Change Request #: |
|
|
Date Submitted: |
|
Date Required by: |
|
|
Related Requirement(s): |
|
Related Issue(s): |
|
|
Submitted by: |
|
Contact Phone: |
|
|
Description: |
|
||
|
Attachment(s): |
|
||
|
Reason: |
|
||
|
|
|
||
Technical Evaluation |
|||
|
Technical Consultant: |
|
Date: |
|
|
Conclusions: |
|
||
|
Project Manager: |
|
Date: |
|
|
Conclusions |
|
||
Budget/Project Impact Evaluation |
|||||
|
Project Manager: |
|
Date: |
|
||
|
Change of Scope? |
Y/N |
Description: |
|
||
|
Technical Consultant: |
|
Date: |
|
||
|
Summary of Work Effort Change: |
|
||||
|
List of New or Changed Tasks – Projected |
||||||
|
Task ID |
New? |
Description |
Budget Hours |
Est. Hours |
Total Chg |
Cost Change |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Totals |
|
|
|
|
||
Risk Evaluation |
||
|
# |
Description |
Risk Resolution Strategy |
|
|
|
|
|
|
|
|
|
|
|
|
Determination |
||||||||
|
|
||||||||
|
Approved: |
|
Rejected: |
|
Deferred: |
|
|
||
|
|
||||||||
|
Reason: |
|
|||||||
|
TRIRIGA Project Manager: |
|
|||||||
|
Signature: |
|
Date: |
|
|||||
|
Customer Authorized Representative: |
|
|||||||
|
Signature: |
|
Date: |
|
|||||
Execution |
|||
|
Assigned to: |
|
Target Completion Date: |
|
|
Priority: |
|
||
|
Instructions: |
|
||
|
Attachment(s): |
|
||
|
Completed by: |
|
Actual Completion Date: |
|
Acceptance |
|||||||||
|
|
|||||||||
|
List of New or Changed Tasks – Actual |
|||||||||
|
Task ID |
New? |
Description |
Budget Hours |
Est. Hours |
Total Chg |
Cost Change |
|||
|
1 |
|
|
|
|
|
|
|||
|
2 |
|
|
|
|
|
|
|||
|
3 |
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|||
|
Totals |
|
|
|
|
|||||
|
Customer Authorized Representative: |
|
||||||||
|
Signature: |
|
Date: |
|
||||||
Strategies for Managing a Mobile Team
Posted by Brad EgelandI ran across a great document put together by Terrence Gargiulo for Makingstories.net. Mr. Gargiulo discusses what he feels are the top ten strategies for managing mobile workers. His full document is a very good read because he also discusses things such as risks and issues to consider when managing mobile workers. You can access his full document here.
I’m sharing this here because so many times as project managers we are overseeing the work of a very geographically dispersed team. In the past three years I’ve only managed one project with a team that I could see on a daily basis. Dozens of others involved remote workers all around the country.
Here are Mr. Gargiulo’s Top 10 Strategies for Managers of Mobile Workers as described in his document.
Top 10 Strategies for Managers of Mobile Workers
1. Focus on building relationships
You are now in the business of managing relationships. Once a quarter audit your time. How much time are you spending engaged in activities meant to foster stronger relationships with your mobile employees? Rate each relationship on a scale of 1 to 10 where 1 is weak and 10 is very strong. Craft a strategy for continuing to develop your strong ones and triage the weak ones. Ask yourself why they are weak and what you can learn from them. Avoid finger pointing and hold up the mirror to reflect on your own opportunities for improvement. Extreme cases of under-performance do not warrant time or effort. These however are few and far between.
2. Streamline communications
Consolidate and prioritize communications. Use email and IM (instant message), texting, blogging, threaded discussions, etc. for relationship-driven communications (i.e., staying in touch and being personal). Communications of an important nature should be cohesive and never delivered in fragmentary pieces that have to be cobbled together by the receiver. Mutually assess the communication preferences of yourself and your team members to develop a communication plan. Avoid assumptions and revisit your plan on a regularly basis especially when the nature of the work is about to change.
3. Incorporate less didatic forms of communications
Determining the right amount of detail and when to provide detail is an ongoing responsibility of a manager with a mobile worker. As a general rule, less is more. This leaves bandwidth for the times when lengthy, explicit instructions and information are essential for the work at hand. Try working with more story-based forms of communications. Sharing tidbits from the field and office in the form of stories, anecdotes, case studies (use cases), jokes, innocent productive gossip, and even metaphors will relay context, encode key pieces of information, and give mobile workers a sense of inclusion.
4. Spend more time listening
Obvious, but counterintuitive. When you are out of easy reach and you are tasked with managing the performance of others it’s easy to get sucked into the trap of needing to transmit lots of information. In most cases the opposite is what is most productive. Make listening a priority. This is the hardest and most tiring aspect of managing others. It is also the single most important thing you can do accelerate the development of strong relationships. Listening is not enough. Keep an open mind. Be present and try to enter the perspective of the speaker. This will help you ask effective questions and identify what direction to go with your own needs and agenda. You’ll be surprised at what emerges.
5. Let mobile workers define communication and reporting practices they want to follow
Structure is critical. Adopt rules of engagement that place people at the center of their own decisions. Managers provide the boundaries and constraints but let employees define the working and communication styles, tools, and processes that will help them perform at the best. Set expectations on two fronts. First, treat these employees’ defined practices as privileges that can and will be modified if key performance metrics are not hit. Second, let employees know there will be times when a projects or work require less flexible, employee-driven communication and reporting practices.
6. Manage deliverables, not activities
Lots of project-oriented work is well suited to mobile workers. Even roles that are more task driven can be effectively managed if they are broken into deliverables. For mobile workers this may mean collapsing some of the activities of a business process or workflow that had manual checkpoints and controls associated with them into deliverables. Automation where possible can be used or batching activities into larger groups can transform task oriented jobs into deliverables. Realize that there can be many facets of people’s jobs that need to be adjusted to accommodate a mobile work style.
7. Engage in more frequent and informal performance management activities
When you manage mobile workers, relationships are at the heart of your job. Performance management does not need to be a loathsome, “administrivia” obligation. Designing some unstructured, informal ongoing dialogs with mobile employees about their performance goals and personal development plans is a great way to strengthen communications, and shows an active interest in employees and relationships. This might look and feel very different from one employee to the next. This is another tangible way managers can adapt their style to match the needs and preferences of employees. It works best when the performance management conversation flows in both directions.
8. Give complete trust until given a concrete behavioral reason to do otherwise
According to a recent survey conduct by HR.com and ic4p, listening and trust are the two most important factors to virtual and remote teams. Without trust, relationships are bankrupt. Abuses of trust can always be found but these occur in spite of whatever systems we put in place. Mobile workers thrive when managers give them complete trust. In some respects managers of mobile workers have no other choice. Use trust to create strong relationships. When some concrete behavior and not just someone else’s word of mouth shows that trust has been violated, then take it away, but not until then.
9. Use adaptive management styles tailored to individual workers
Every employee is different. Mobile workers make it easier for managers to take a more personalized approach in how they work and interact with members of their team. It takes more work and effort on a manager’s part but the results can be phenomenal. Understanding what enables each employee to perform at his or her best is the most important responsibility of a manager.
10. Leverage technology
Technology drives and supports managing mobile workers. Using technology well is not as simple as it appears. Standard models of communication and transaction should not always be mapped in a simple one-to-one way. Communication and collaboration technologies offer new and exciting models. These need to be purposely exploited in order for organizations to realize the full extent of benefits these wonderful new capabilities and features offer.
Beyond email, IM and phone, Web conferencing plays a key role in virtual team enablement. Take an inventory of “stuff” you need to collaborate on with your virtual team. If the list includes Word docs, spreadsheets, software applications, or anything else on your desktop, Web conferencing will be critical for collaborating in real time. You’re projects will lag if you can’t be on the same page with mobile workers.