Failure sometimes is inevitable. But fail fast and failover.
Why, can CIO play as Chief Inspection Officer to diagnose the root cause, also play as Chief Improvement officer to develop the best scenario possible in improving project success rate? Here are three aspects which need consideration to improve project success.
1. Project Sponsorship & Success Definition
1) Is the project justification valid? Do you get top management support and backing to the project? To dig further, just because the sponsor promises a 40% first-year ROI, can the resultant new product or service deliver? Who confirms the claim - particularly from highly-placed sponsors - before committing tight capital, is there follow-up a year later to validate? Is a portion of the sponsor's incentive tied to the products or services (not just project) delivering on the initial ROI (or NPV) claims?
2) Have all key project stakeholders been identified? And have they been involved/ participated appropriately in the project initiation efforts? Is the sponsor driving the stakeholder identification/participation activities? How about governance body, such as Project Steering Committee Meetings involving key decision makers to steer the project to success by taking a critical decision on the processes and project related issues. Whether it is embarking on projects for improving customer satisfaction, operational efficiency, increasing revenue, reducing costs, or any other value-add, the business must engage a technology steering committee. Reporting framework in each domain should be mapped and developed to ensure implementations meet business users reporting requirements
3) Have you defined success up front, before a project is undertaken? It is critical. This should be done at a business level. As you descend into the implementation, then good requirements gathering, project/risk/change management, methodologies, and quality assurance facilitate a successful implementation. Continuing to review the following key areas are crucial high-level components to every project:
- Project Purpose - Why was the project undertaken
- Project Owner/Sponsor - Who is ultimately accountable (Funding / Success)
- Communication - Set expectations upfront and communicate regularly
- Project Purpose - Why was the project undertaken
- Project Owner/Sponsor - Who is ultimately accountable (Funding / Success)
- Communication - Set expectations upfront and communicate regularly
- Stakeholders - All roles need to be represented
- Requirements - Elicit and document Business, User and Solution Requirements
- Expectation and Change Management will be critical for successful project
- Milestones - Evaluate progress regularly and openly
- Partnership -If an external partner is engaged, does that partner have the ability to deliver? Who will manage the partner's performance? Does that person have sufficient authority to be effective?
- Post-Project phase: Until project organizations treat the post-project audit as an integral part of the project effort, project teams will continue to reinvent solutions, with attendant risk.
-Training, training, training
- Post-Project phase: Until project organizations treat the post-project audit as an integral part of the project effort, project teams will continue to reinvent solutions, with attendant risk.
-Training, training, training
2. Project Requirement Management
1) Are project requirements clearly articulated in writing? As Requirement Management is often an art versus a science, the business analysts and technical analysts are crucial for eliciting requirements properly and documenting them clearly for use throughout the project. However, collecting a laundry list of functions and features (which is what a requirements list usually is) just doesn't work. The business rarely thinks of everything and always wants to add more functions and features. For many large organization-wide projects, gathering system requirements may take years.
2) Further investigation: In addition, you don't know which functions and features are personal preference vs. a real business need. To further ask: Have quantifiable acceptance criteria been associated with each requirement? Have both requirements and acceptance criteria been approved by the sponsor and all key stakeholders? Is a formal Change Management process in place?
3) Have businesses first describe what result and benefits the business is trying to achieve. Perhaps this is a better approach. You can then make sure the IT solution is focused on the result/benefits, not individual user preferences. You then need to have the business area owners (not a general user) describe how the business process flows and what variations in the business process (scenarios) they expect. From this information, IT should then design a solution (whether it’ll be a package or custom) and validate with the users. The validation should focus on why the proposed solution will NOT work instead of turning it into a session to collect more desired functions and features (which is what typically happens with requirements based approach). This approach also ensures you don't have a bunch of new requirements "pop up" during testing since testing should be based on the business scenarios documented during design
4) Has IT been involved right from the start and determine the potential for synergy?The IT participants should be encouraged to contribute their creativity and expertise at an early stage to make system modular and flexible. Through that participation, their engagement in the company's business goals also will increase
3. Project and Portfolio Management
Organizations shouldn’t confuse the purpose and role of Project Management and Requirements Management into a blurred mash pit. These are separate but interdependent entities with their own respective knowledge areas. One person or multiple people may play these roles; they just need to be aware of which hat they are wearing as they address their stakeholders as well as other project members.
1) Are the project and schedule realistic - or have they been reduced without equivalent adjustments to scope? Inevitably, the PM has their hand on the throttle and heartbeat of the entire project. The CSFs and KPIs identified upfront play a big part in identifying what will determine success or failure of a project. In the end, the project stakeholders need to give thumbs up or down not based on feeling, but on facts. A PM is concerned about the triple threat of Scope, Time, and Resources.
2) Do PM & PMO have the ability to get things done without compromising quality? The delivery of the project is based on the PMs ability to get things done, manage /mitigate risk and issues, communicate/communicate/ communicate with team members and stakeholders. Every PM is unique in his/her delivery methodologies, but PMs don't have the time/resource to create and measure organizational standards, for any large environment delivering enterprise programs, the PMO, is responsible for guidance, standards, and tools, to ensure the project effectiveness, conduct requirements gathering process, take those requirements and develop project process that are manageable and ensures consistent delivery methodologies and continually deliver projects successfully.
3) Is your PM flexible or bureaucratic? Being flexible, but avoiding bureaucracy is also the key. The system of work (with functional silos, lots of hand-offs, a command-&-control approach to work, responsibilities and authority) create barriers to managing the project effectively. Methodologically, if Waterfall is used, you may be a victim of the structure that it creates. If Agile, there are also pitfalls to watch out for. The management and engineering discipline are even more critical when running Agile
2) Do PM & PMO have the ability to get things done without compromising quality? The delivery of the project is based on the PMs ability to get things done, manage /mitigate risk and issues, communicate/communicate/ communicate with team members and stakeholders. Every PM is unique in his/her delivery methodologies, but PMs don't have the time/resource to create and measure organizational standards, for any large environment delivering enterprise programs, the PMO, is responsible for guidance, standards, and tools, to ensure the project effectiveness, conduct requirements gathering process, take those requirements and develop project process that are manageable and ensures consistent delivery methodologies and continually deliver projects successfully.
3) Is your PM flexible or bureaucratic? Being flexible, but avoiding bureaucracy is also the key. The system of work (with functional silos, lots of hand-offs, a command-&-control approach to work, responsibilities and authority) create barriers to managing the project effectively. Methodologically, if Waterfall is used, you may be a victim of the structure that it creates. If Agile, there are also pitfalls to watch out for. The management and engineering discipline are even more critical when running Agile
Failure sometimes is inevitable. But fail fast and failover. Go beyond IT failures, IT develops the professional competencies needed for successful business solution delivery, IT captures organizational knowledge to continuously improve performance, The IT and stakeholder departments have clear objectives, processes and indicators with clear accountability and responsibility to deliver business objectives and implement business strategy steadily.Through a series of questions above to investigate upon the big WHY of project failures, the goal for CIO is to build up the better standard with necessary flexibility in order to improve project success rate overall.
Read More about magic "I" in CIOs:
CIO as Chief Interpretation Officer
CIO as Chief Imagination Officer
0 comments:
Post a Comment