By Peter B. Giblett
Project management has traditionally been one of the hottest topics in business. There is a perception (largely unfounded) that the majority of projects fail. David Wright recently published an article “13 Steps to Better Projects” in ComputerWorld Canada in which he offers a personal view to overcoming change. I would like to commend his article, but I do take a slightly different view.
To my view the majority of the reasons for project failure is our desire to fix the world in one massive step. Additionally we should consider that today there is no such thing as an IT project, there are simply business changes projects that have IT deliverables.
It is often stated that IT must pick the right project for the business, but it is the business that must determine its priorities for change and manage such projects as needed to achieve that change. IT has a great history in delivering projects, in fact unless you are in the building industry, or perhaps advertising, it is the one part of the business that really knows how to deliver projects – because it has been doing it for decades. Today when business identifies a need to change it’s processes it is assumed that IT systems must change, however this is not necessarily the case. It is quite feasible to change a business process without impacting the underlying system.
Business is in a state of continuous improvement. Look back at the first company you ever worked for, it is unlikely to be run the same way today as it was back then. Improvement will continue to be needed as long as we have business. Improvement is needed even outside of business (e.g. in non-profit areas).
Where there is a culture of improvement there will be projects to facilitate change.
Projects are always limited by time and resources. One of my early projects failed, not because of the quality of the technical delivery but because of the quality of the data delivered to the user – this failed to meet their requirements. After a rebuild I decided there had to be a better way. There is, it requires continual business community involvement. The best successes I have experienced are where users and developers work in a shared workplace and were able to make decisions that impacted the success of the project.
I agree about the need to break projects down into byte-sized pieces, I think we should be looking for continued deployment on a 6 to 12 week cycle. In deploying IT solutions it has commonly been stated that 80% of the business benefit comes from 20% of the defined requirement. If we deploy through a single big-bang approach we can often spend 40% of the project time delivering a component that is required by only 10% of the user community and represents only 5% of the value of the system. Where is the sense it this?
So if we turn this around we can see that delivering 20% of the functionality can offer significant benefit to the business. But of-course this is by no means a complete delivery, we cannot put away our tools and go home leaving the business happy with what has been delivered. This is only the first stage. From this point forward it is important to continue to deliver in a set of well defined stages, each building of the success of the last stage. This approach works well because the business community is involved in delivering products that impact the daily lives of these subject matter experts, who of-course broadcast the good news to their buddies in the business. Of course if you are worried about testing, documentation, and quality assurance this is embodied into the whole approach and carried out through the project life-cycle. Each project stage should be delivered on-time and in-budget with productionisation and operationisation as part of these deliverables.
This approach is supported by the DSDM method, which is one of a variety of Agile approaches to project management. IT Governance rules (such as Security, Risk, Service Level Agreements, etc.) of-course all need to be satisfied. But it should be remembered that deployment of a single stage does not equate to deployment of the whole project – full governance rules will be completed in time.
Once a project is under way it is vital to complete it, not just this stage of the project.
During the course of an individual project stage it is necessary to ensure that forward progress continues. We have all seen it, that task on the project plan that has been at 95% for the last 6 to 8 weeks. One of the key components of an agile approach to project management is to ensure tasks once started are completed quickly – if they are not completed in 1 or 2 weeks then it is likely they need to be cut-out of the current stage and ring-fenced for a future investigation. Remember the project is tasked with completing the deliverable, not the task. It is this type of in-action that can often doom a big-bang project – nothing is ever marked 100% complete, we have all seen it before!
It is possible to deliver even the largest of projects, such as ERP and CRM applications through the deployment of agile methods. Although in my experience the the project manager from the professional services arm of the solution provider can be the biggest barrier to success.
If you are implementing a Data Warehousing or Business Intelligence project agile solutions can seriously improve the acceptance of your project!
