项目的成功取决于什么？以前从来不会思考这些问题，直到前天QA开玩笑说我们做了个烂项目, 我随口一答“一个项目的成功取决的Product Designer，Manager和Tech Lead，与我们这些底层无关”。
言下之意，有Product/Project Manager统管项目大局并控制风险，有Product Designer定义产品，有Tech Lead则把握着技术方向并负责最终的实现，他们在一个项目的中表现基本上决定了项目能否成功。虽不免有为Developer开脱责任的嫌疑，但粗看来还是有些道理。如果一个产品与用户的需求背离或者丝毫引不起用户的兴趣，那Product Designer有责任；如果项目做得战战兢兢，总是充满了不确定性，Manager必定脱不了干系；而作为Tech Lead，如果总在不同技术方案之间摇摆贻误战机、无法控制质量或不能促进团队的技术进步，很容易导致最终项目的失败。
不过细细想来，自然不会那么简单，一个项目的成功，取决于太多因素，甚至成功本身，也还需要认真定义。同时，从不同的角度来看也是不一样的，比如对于个人来说，项目做完，工资到手，项目成功，拿到bonus,项目挺成功。从客户角度来说，最终的产品是否能派上用场才是项目成功的标志；而对于企业，他们关注进度、财务支出与市场回报。
那从企业的角度来说，项目的成功如何来定义，成功到底取决于什么呢？ 我们看看科班们是怎么来分析的：
Project success = project management success + project product success
-------------------------------------------------------------------
Project Success:
Product Success:
-------------------------------------------------------------------
从Project Management Maturity Matrix看来，项目成功有四个水平：
-------------------------------------------------------------------
Level 1: Project Management Success (cost, time and quality)
Did our project produce the desired output?
Level 2: Repeatable Project Management Success (predictable outcomes)
Do our projects consistently produce the desired outputs?
Level 3: Project Success (benefits realised)
Do the project outputs produce the desired outcomes?
Level 4: Corporate Success (strategies implemented, value added)
Do the outcomes produce or have the intended impact on the business strategy?
Moving from one level to another requires organisations to develop processes in a number of areas:
- A methodology is required to move from level 1 to 2
- Benefits management is required to move from level 2 to 3
- Project portfolio management is required to move from level 3 to 4
-------------------------------------------------------------------
How to Ensure the Success of IT Projects
-------------------------------------------------------------------
There is a noticeable difference between the 90+% success rate claimed by IT managers for their own projects and reports from industry observers that less than 50% are successful. This does not reflect a difference in the facts, but rather in the definition of what constitutes “success”.
If success includes all projects that are actually delivered by IT to the business, the success rate may well be as high as 90%. However, this includes projects that exceeded the projected budget or time-frame, were not accepted by the users or failed to meet the business objectives that allowed their budget to be approved in the first place.
If success only includes projects that “Go live within the projected budget and time-frame, meet the stated business objectives and continue to function throughout their planned life-spans without major hiccups or incurring significant, unplanned costs”, the success ratio is probably closer to 20% than 90%.
Most CEO’s define success using the second metric, so this is the one adopted in this paper and it drives what issues need to be considered when working to ensure the success of IT projects.
Requirements Specification
The Requirements specification provides a clear definition of the project scope, and is the foundation from which the Engineering specification and hence priorities, project milestones, dependencies and other documents are derived.
It also provides the definition of success for the project, expressed in business terms, not IT terms. Specifically it must be expressed in terms of the business stakeholders and this illustrates why stakeholder identification is key, a missed stakeholder can kill the project.
The key to winning top management commitment is to address their needs. For a project to be successful it must address a particular "pain" in each affected stakeholder in a business process. By understanding stakeholder pains, an experienced project leader should be in a position to present what the project is hoping to achieve from different viewpoints and thus reach a common understanding which will eventually lead to everyone pulling into the same direction.
One critical issue that must be addressed in the Requirements Specification is what the system will be like to use. End users satisfaction is critical, yet it's common for leadership to be insulated from the concerns of the end-users because people are afraid to complain to the big boss.
Identify influential people in the organization and study if the project objectives and the individual power centers are in line. Else develop a strategy to bring them in line.
Effective communication
Schedule a meeting to discuss the project goals as laid out in the requirements specifications and confirm that the project is headed in the right direction before allocating the resources to get it there.
Have brief (15 minute) daily status meetings and longer weekly meetings to ensure that everyone is up to date with progress and to give the business managers the opportunity to suggest course corrections if the business needs have changes.
Keep stake holders up to date with project management software that automatically sends periodic updates and escalates issues when a dependency is late. When a team member leaves, the project management software may automatically assign their issues to a manger for a permanent re-assignment.
Maintain upward, downward and lateral communication and define a preferred method of communication for each stakeholder.
Engage people (inside and outside the project) and ignite the human spirit. Find people willing to deliver on what they commit to... and allow people the space to "contribute and make a difference.
Capture all communications, at all stages of the project, including relevant e-mails. These will help you when you create the final project handover documentation for the client.
Till the end of the project delivery you will face obstacles and in some cases pressure from the senior management, this is where assertive communication skills and a clear change management process are needed.
Engineering Specification
The Architecture section of engineering specification describes exactly how the requirements are going to be implemented.
Custom coding introduces the greatest level of risk so it should be avoided where possible. Code always contains bugs that take time and effort to flush out and despite the best efforts of some very smart people, with various development methodologies and IDE's, bug finding/fixing remains unpredictable. The typical ratio of costs for bug-fixing/maintenance compared to initial development to 4 to 1
If custom coding is required, set expectations that the project may take much longer than expected and budget for significant ongoing support/maintenance costs.
Avoid gold-plating as much as possible.
Project Time Line
Problems and unexpected events will always exist in a project, no matter how big or small. It's how the Project Manager deals with these elements that make the difference between success and disaster. You need someone tenacious, and fearless.
A rule of thumb is to plan in as much detail as you can to come up with a resource and time requirement, then double that estimate - it always takes longer as things always happen that you haven't planned for.
Contingency planning! When you create your project plan, add time for the 'unknowns' that you will discover along the way. Build a few extra hours into some tasks which add up to 1 or 2 days. And, most importantly, when you have your project definition kick off meeting, you must stress the importance of delivering on time and under budget.
Motivate your team by talking about the positive visibility you will have when you deliver on time.
Engage the team by asking for their commitment to communicate any delays they discover to the project manager right away. You must go around the round table and ask each person "do you agree with the project plan and how we need to manage it?" and "do you have ideas/suggestions for a better way to manage the project?" Write these two questions on the white board and as you ask each team member, put their initials that they agree. This visual aid - the white board or the poster paper will be remembered most. Then follow up with the meeting minutes. Make those brief but get the two questions in there and that the entire team agreed to this approach. Hold people accountable. Make sure you fully understand any delays they mention to you and document those by adding a note to the task in the project plan.
Early demos
A system cannot be fully demonstrated until it has been developed, but this is no excuse for not providing some kind of prototype. A software mockup without a working back-end can provide a reasonable facsimile to the planned system at a cost that is trivial compared to the actual system and should be included as an early milestone.
Here is a true story that illustrates what can happen if the end-user is not considered. A very large hospital in Los Angeles area implemented an Electronic Medical Record, spending $10M+ and a very large engineering effort. Everything was delivered as per the scope, budget and quality you can expect from a reputed vendor. Unfortunately, the clinicians refused to use the system forcing the hospital to scrap the system and write off the entire investment.
Effective training
Train the users in a test environment before it goes live. Gather feedback during this training and plan on modifying it based on their input.
Use Efficient Tools and do not Re-invent the Wheel
It is a lot easier to finish a race in 5 minutes if you start 10 yards from the finish line than if you start 10 miles back.
Enterprise IT projects generally require a web interface, auditability, dashboards, automated backups, security, web services/REST API's, reporting, searching, synchronization with other systems, data integrity constraints, export/import capabilities and more. The more core facilities are provided by the platform, the less needs to be developed.
Everyone is competing for the IT dollar and business managers will go outside if they cannot get the level of responsiveness that they need internally.
Example: When a business manager asked his IT department for a quote on developing a tool for managing COCOM compliance, he was told that it would take about six months effort using Lotus Notes. An outside vendor quoted him three weeks as a fixed price contract and got the job. From the perspective of the business manager, IT failed before they even started.
Yet the IT department could have installed the vendor's framework on their own server and configured it in exactly the same way. Apart from needing a week of training to come up to speed on the technology, they would have been in exactly the same starting position and when IT delivers a finished product in less than a month, they look like heroes.
Another example: At another company, a development manager was planning, and had actually begun writing, a comprehensive document on the coding standards they should use for J2EE development. Twenty minutes research on Amazon brought an entire book on coding standards. Incidentally, the critical tool in this case was not so much the availability of the book, but the rating system that made it easy to find the definitive work on the topic and so avoided a lot of argument.
QA Process
A good QA process is very important. Ensuring a level of quality is in place reduces negative perceptions from the end users of failed projects. The QA team ensures that requirements and functionality are in tack before end users get a hold of the product. It only takes one negative view to domino the perception that the project is a failure.
Risk Management
Prepare for the worst. Hardware may fail; users may demand changes and staff may be unable to meet their commitments.
Have a plan B in place before you need it, not when disaster strikes and people start slipping into panic mode.
Be willing to take calculated risks and be transparent and open regarding all project setbacks and escalate in good time. Bad news can be dealt with if it is early. Bad news late is a disaster!
Gather sufficient information about past projects in the organization, their success stories and disaster stories. Analyze reasons for success and failure and make use of your assessment in the current project
Obtain estimates for remaining work on a task in workdays rather than % complete.
Integrated Change Control
True success includes adoption of change in the trenches. Make sure that your requirements translate into change such that the outcome is actually adopted.
Have a well documented change management process and get it signed off from the client; otherwise clients will believe that it is their right to change the requirements whenever they want without understanding the process.
Making prudent use of document and/or code repositories for collaboration and unification across development teams is a great help for successful delivery of projects. By using knowledge base and search tools the iterative process being done by collaborative teams can be managed throughout the project life-cycle. Some application development environments come with these tools built in. Training and full use of such programs will certainly keep the scope, design, and development in check as everything is run through the disparate teams on the way to implementation and delivery. Many more eyes are able to quickly examine the routes developers are taking at any time, which will give the opportunity to head off potential scope creep and re-coding of available classes and modules.
Effective Project Manager
Having an effective project manager is critical and this paper describes actions they can take to ensure the success of the project. The following suggestions are intended to help you hire an effective project manager or indeed other IT employees, but first lets clear up a couple of myths:
Myth 1: Interviews Are Effective
The exact number depends on the interviewer, but researchers have found that typical interview accuracy rates are only 30% better than random selection. Further, there is almost no correlation between how good someone thinks they are at interviewing and how effective they are. If you have never hired a dud employee, congratulations! If you have, read on.
Myth 2: Checking References Improves Outcomes
Not only are many employers too afraid of lawsuits to give bad references, some will even give excellent references to help rid themselves of problem employees. In general the only thing harder than finding a good employee is finding a bad reference.
Prior experience is an excellent indicator of how much money employees will want, but a poor indicator of how well they will actually perform.
A More Efficient Process
Of course, interviews, reference and background checks are an essential part of the hiring process, but they should not be the sole criteria. Here is a suggested process:
Create custom web forms for each job opening and set up business rules to prioritize and/or auto-reject candidates based upon information provided in the form. For example, you can ask them to take a quick online test and include the result in their application. Appropriate rules can eliminate 70-90% of the candidates without any effort on your part.
Ask the remaining candidates them to take an online aptitude test for that specific position. Depending on the position, only the top 10-20% progress to the next stage.
Only hire candidates who achieve unanimous buy-in from team members. Immediately make a job offer, contingent upon reference, credit and criminal background checks. Do not keep them waiting or another employer may step in.
A disciplined, automated hiring process can not only free up your time and ensure you find the best possible candidate, it is objective and can be audited to demonstrate an absence of bias.
Team resourced with the right expertise
This might seem obvious, yet projects often flounder because the participants did not have the necessary expertise.
The Milestones section of the Engineering Specification should include a description of the required expertise to meet this milestone and which team members will provide it. Where applicable, these team members should have objective test results to confirm they actually have the required expertise.
Transparent Work Flow
The tool should make it clear what the workflow is for any given process and how this process has been followed in any particular instance. Since most people are not programmers, this implies that the workflow representation and its application must be accessible to non-coders.
Infrastructure
Many IT professionals who are "software focused" don't include this topic in their planning - and so many projects that do a great job at meeting the functional requirements fail upon implementation.
The hardware infrastructure at many companies is in bad shape even before new loads are introduced, with predictable results.
Plan for at least double the "expected peak" load and assume that any given piece of hardware, including motherboards will fail
An assessment of the state of the starting (i.e. current) infrastructure should occur at the start of a major software project. As many software professionals do not have strong infrastructure experience, it is wise to hire a consulting firm or use a IT Infrastructure Assessment tool to conduct an objective survey of the reliability, utilization, performance, capacity, and design of the major components.
A key outcome is to identify the risk of the current infrastructure, it's current weaknesses, and provide data to forecast the loading of the components when the new (additional) application(s) are fully deployed.
Experience demonstrates that lack of capacity or poor infrastructure design leads to high latency, application timeouts, and random errors due to high loads that are nearly impossible to troubleshoot - yet consume a large amount of software developer resources.
Capacity planning is a key process that many small and medium size organizations do not perform on a regular basis. Subjects to be included in a capacity plan should include:
- Servers
- Web Servers
- Storage
- Networks
- Desktops
- Printing
- Database
- Telephony
- Data Center
Supplier Management
Build performance clauses into the contract, including the ability to walk away without paying if they are significantly late.
In order to avoid re-inventing the wheel, most IT projects will be built upon third party software. Here is a vendor checklist to consider for the software and supplier, though not all items are relevant to all projects.
Auditability
The system must be auditable in multiple senses to ensure compliance with Sarbanes-Oxley and other regulations. It must make it easy to show an auditor what a defined business process is, how the system enforces the process, and how the process has been followed in any particular instance. Further, the solution should make it possible to capture and collate data, such as who logged in, what IP address they came from, what records they viewed, edited, etc.
Integration
The solution should include pre-built integration with standard technologies, such as LDAP/Active Directory and MS Exchange. It should also support a robust set of APIs and scripting options, including Web Services. Ideally, even the source code should be accessible – not that you’d want to change it any more than you’d want to use an emergency parachute, but it is nice to have the option.
Adaptability
Once the system has proven itself in the initial deployment, it should be easily extensible to other business areas. So the data models, business rules, workflows, access permissions, and data input forms must be fully and rapidly customizable.
Scalability
The solution must scale to support thousands of current users, the update of hundreds of thousands of records per hour, and databases containing tens of millions of records, without requiring non-commodity hardware.
Security
The system must support a fine-grained security model for precise access control. The software platform, and if SaaS based, the hosting infrastructure, should be subject to regular security audits from an independent firm and the vendor should make the results available.
Uptime
For SaaS based products, vendors provide up-time guarantees that reflect their confidence in the availability of the service. Some vendors just offer a pro-rata refund, while others return the entire cost of that month’s service if the target up-time is not met. If the product is installed in-house, it should support high availability options so that service can continue even in the event of a motherboard failure.
Reporting
The system must support dashboards, charts, and reports that provide quick insight into business processes. But passive access to information is not always enough, so it should also support the creation of business rules that provide active notification of any problems.
Standards Compliance
The system should support standards such as HIPPA, ADA, ITIL, and CFR 21 Part 11.
Platform Choice
The vendor should offer a SaaS option so that customers don’t need to provision a server to get going. Once the solution has proven itself, it should be movable to their choice of in-house Linux or Windows server to allow full integration with sensitive back-end systems without impacting the firewall.
Web Based to Reduce Maintenance
The product should be 100% web-based so that no installation or upgrading of client software is required. It must support the customer’s choice of browser.
Backups
System backups should be fully automated and include everything necessary to move the entire deployment to another server or to restore in case of disaster.
Upgrades
Upgrades should require little effort and must allow migration from any revision to any later revision without affecting customizations.
Cost
The cost to get started must be reasonable and the product should provide a rapid ROI, ideally within the first few months of use. Getting a reasonably complex production system up and running should be reasonable (e.g. $50,000) and extending the system to cover new processes should be low. The cost structure should be simple and inclusive, without hidden extras or per module or per function charges every time you want to extend the system.
Vendor Independence
IT staff should be able to extend and maintain the system themselves after training, rather than tying the company to long-term dependence on $200-per-hour consultants. Ideally, the training time should be short. Systems designed to be maintained by the users may require a week of training to reach proficiency, whereas those designed without this criterion in mind may require over a month of training and carry increased effort/risks when making changes.
Company Stability
The vendor should have a ten-year or more history of providing enterprise solutions. For CIOs of large companies, the vendor’s track record with other Fortune 500 companies is most relevant. For start-ups, experience with small companies is of greater interest. The vendor should be financially sound and profitable.
Low Risk
The vendor should be able to describe exactly how the software addresses current business need(s) and demonstrate it running this exact process prior to purchase.
The vendor should be willing to commit to a fixed-price implementation for the entire project based on a mutually agreed specification.
Different vendors may offer different forms of refund if a project fails, ranging from a credit towards additional software purchases, to a full cash refund of all software costs and consulting services. The strength of the warranty indicates the vendor’s confidence in their software and implementation services.
Vendor Summary
Different CIOs may prioritize their requirements differently from this list, but it should serve as a useful starting point. The extent to which these requirements are supported varies widely among vendors.
The above guidelines are not just theory, but the collated wisdom from hundreds of CIO's and senior IT mangers,
Provided that they are followed carefully, these recommendations effectively guarantee the success of your project, but they are not a magic bullet. They require discipline and hard work to follow and some involve a significant lead-time. For example, it takes a lot of patience and money to hire first rate staff and project managers.
As a practical matter, we use these guidelines at when implementing IT projects, either as an outsourced service or when jointly with the IT staff and business managers. After hundreds of deployments, we have not suffered a single failure.
The cost of following a disciplined approach to IT project development is generally more work "up-front" to effectively scope the project, find the best suppliers and setup the right team and infrastructure for managing it. The benefits are a major reduction in delivery time-frames, reduced costs, improved transparency and almost certain success.