Managing the Strategic IT ProjectSometimes, the customary big bang approach can do more harm than good
by Sanjay Murthi Continued from Page 1 Skills sets are usually different between the two teams. Deployment teams will be more support oriented; implementation teams will be oriented toward creating new or modified solutions. The implementation teams will also be more skilled and experienced with the tools being used to create the application. Both teams will need to work closely with end users. Implementation teams need to understand what solutions would be good for users. Requirements will frequently change as users become better aware of what's available. The implementation and deployment teams should work closely together. The deployment team is like another set of eyes to the implementation team in terms of working with end users or customers. The stabilization phase is usually a good time for the implementation team to train the deployment and support team and familiarize them with the new features from the next project. The iterative project style helps make the deployment and support team become experts in troubleshooting issues as they become familiar with each project's deliverables. How it WorksIn some cases, it may be hard at first to break a project down into smaller subprojects. Consider the example of a global pharmaceutical company deploying a packaged analytic application across multiple research and development organizations. The application will be used by different research department, such as chemists, biologists, drug development teams and so on, so some customization may be required in different areas based on the unique data access and analysis needs of each department. How can we break down this project that's planned across several months into smaller projects? It makes sense to identify different configurations of the analytic application required by the different groups. Each configuration will involve specific customizations and configurations required for the package. Some will be similar, while others may have nothing in common. For example, one set of the package's configurations will allow biologists to identify promising biological agents from thousands of high throughput screening (HTS) results. Another set of configurations could help analytic chemists review test results on different chemical compounds used in drugs. In this case, we could define smaller projects, each delivering some of these configurations. We could also plan to develop each group of configurations in turn. It would also makes sense to try and finish the easiest configurations first, which would reduce the steep learning curve required for such a complex package rollout. Completing the easy configurations first would also help the organization to get value out of its investment quickly. Because a specific configuration appeals to the needs of some end users, it also makes it easier to get them to start using the deliverables from a project in the iteration. This is a big challenge because many users tend to treat intermediate applications as shelfware and never get around to using them; if so, you'll miss valuable feedback from the field. However, in our example, if the first configuration made available lets chemists analyze test results stored in some laboratory information management systems (LIMS) databases, there's a good chance that they will start to use it — so even if the new tool doesn't yet cover all the different LIMS databases they have, it's still useful. In the next project iteration, our team may target more LIMS databases and configurations used by other researchers, such as the biologists in the organization. This next project could start off even before we have completed the deployment phase for the previous project. (It's important to have the deployment and support team trained and in place quickly. You wouldn't want your implementation team to have to help each chemist set up a workstation to access data from each LIMS system.) An Approach to RiskRisk is a major area of concern in strategic IT projects. The best way to manage risk is to identify them proactively before they can become problems. Traditionally, organizations perform risk evaluation once early during project initiation and maybe at a later time when things go badly. However, risks change across the life cycle of a project. Risks that were identified today may not be the same tomorrow. For example, when you begin a project, the big risks might be lack of experience with the package, inadequate staff, contract issues, and so on. Later on, these issues might fade away and you could face other risks, such as major bugs in the package that make it useless in most configurations, a company merger that requires you to support research teams using new and unfamiliar tools, and so on. Therefore, you should periodically evaluate potential and active risks with the project team and stakeholders. This 360-degree evaluation is a great way to recognize and evaluate emerging risks. In some ways, this approach is reminiscent of total quality management, where all members in the production team are charged with keeping track of product quality during manufacturing. The iterative delivery model gives you a chance to make changes and respond to risks. Referring back to our example, you may find in the first project that the analytics application can't extract data out of some very important LIMS databases. This limitation could be a real project killer. At this point, you'd have the opportunity to work with the software vendor to make this data extraction work because you're at an early stage in the deployment. You could also explore using third-party or custom-built solutions to access the data. Alternatively, if no solution were forthcoming, you could bite the bullet and shut down the project or change its goals before expending more time and effort. However, if this problem were discovered in a fairly late iteration, it probably wouldn't be too serious because the organization has been getting business value from the configurations that have already been delivered. Stay FlexibleSuccessfully delivering strategic IT projects requires you to be very flexible and adaptable. Big bang approaches frequently result in failure, since they don't adapt well and don't provide ways to detect early on the project risks that change during development. Unexpected risks are a given on any project, and being able to adapt and find ways to get over these problems is crucial for your ultimate success. Sanjay Murthi [smurthi@smglobal.com] is president of SMGlobal Inc. He has more than 14 years of experience in the software industry in a variety of roles and responsibilities. He now helps companies review and improve their software definition, development, and delivery process. RESOURCESThe Standish Group report "CHAOS: A Recipe for Success" (1999) offers a formula for efficient iterative project management. See www.standishgroup.com for details. The Software Program Manager's Network provides a list of "16 Critical Software Practices" at www.spmn.com/16CSP.html.
|
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
| ||||||||||||||||||||||||||||||||
