In a BATimes article John Moore visits the need and proper use of a Business Case document to increase the success of IT business solution projects. He demonstrates a failed project due to a competitor who released a competitive product in the market before our organization’s project completed. The business manager showing the project failed because it did not deliver the projected ROI. The IT project team noted that they delivered the project on-schedule, on-time and on-budget. Was that risk that a competitor could beat us to the marketplace identified at project initiation or during the life of the project? Were the proper stakeholders identified and included in the project communication plan?
John makes note how the Business Case document should be revisited several times during the project life cycle. Doing so may have caught the changing environment and allowed the organization to mitigate the risk from the competitor.
John makes very valid points that I believe show an improper IT solution Project Delivery System. Laura Brandenburg notes in her blog that the Business Case document is often created under another name, or as I have noticed in many organizations the Business Case document is created, then it is used to develop the Project Charter and Project Design documents. These documents should not only be created but needs to visited by an IT Governance body during multiple steps in the IT solution Project Life Cycle; not just at project initiation. At each point it makes a “go/no go” decision as to whether to continue the project. This is where many organizations fail to follow through.
Take the simplified high-level Project Life Cycle that includes 5 phases: Initiation, Analysis, Design, Development and Implementation/Closure. Most organizations will make the “go/no go” decision on an IT business solution project either prior to the Initiation phase that kicks off the project or at the end of the phase, depending on how the organization defines its Project Delivery System. In most organizations that is the only time that the IT Governance body will rule on the value of the project.
If the IT business solution project had to go before the IT Governance body at the end of the Analysis, Design and Development phases as well as the Initiation phase then the organization has greatly increased its ability to mitigate risk in the project, especially from external forces.
As the project goes through each phase of the Project Life Cycle, the benefits, costs, requirements and risks are further defined. In John’s example, if our competitor launched their product while we were still in Design then our IT solution project went before the IT Governance body for its next “go/no go” decision. The IT Governance Body, being aware of the competitor’s product launch, can now say that the project benefits are no longer valid. The risk mitigation plan can be executed, which may include dropping the project all together. This reduces the cost to the organization as those resources can now move on to a more valid IT solution project.
So not only is it important to make sure that you build a Business Case document, by whatever name you may call it, but be sure it is visited several times during the project life cycle, by others outside of the project team, to ensure that the assumptions (benefits, costs, risks) therein contained remain valid. This along with making sure the proper stakeholders are involved greatly increases ensuring that the IT solution project maintains its value to the organization.
John makes note how the Business Case document should be revisited several times during the project life cycle. Doing so may have caught the changing environment and allowed the organization to mitigate the risk from the competitor.
John makes very valid points that I believe show an improper IT solution Project Delivery System. Laura Brandenburg notes in her blog that the Business Case document is often created under another name, or as I have noticed in many organizations the Business Case document is created, then it is used to develop the Project Charter and Project Design documents. These documents should not only be created but needs to visited by an IT Governance body during multiple steps in the IT solution Project Life Cycle; not just at project initiation. At each point it makes a “go/no go” decision as to whether to continue the project. This is where many organizations fail to follow through.
Take the simplified high-level Project Life Cycle that includes 5 phases: Initiation, Analysis, Design, Development and Implementation/Closure. Most organizations will make the “go/no go” decision on an IT business solution project either prior to the Initiation phase that kicks off the project or at the end of the phase, depending on how the organization defines its Project Delivery System. In most organizations that is the only time that the IT Governance body will rule on the value of the project.
If the IT business solution project had to go before the IT Governance body at the end of the Analysis, Design and Development phases as well as the Initiation phase then the organization has greatly increased its ability to mitigate risk in the project, especially from external forces.
As the project goes through each phase of the Project Life Cycle, the benefits, costs, requirements and risks are further defined. In John’s example, if our competitor launched their product while we were still in Design then our IT solution project went before the IT Governance body for its next “go/no go” decision. The IT Governance Body, being aware of the competitor’s product launch, can now say that the project benefits are no longer valid. The risk mitigation plan can be executed, which may include dropping the project all together. This reduces the cost to the organization as those resources can now move on to a more valid IT solution project.
So not only is it important to make sure that you build a Business Case document, by whatever name you may call it, but be sure it is visited several times during the project life cycle, by others outside of the project team, to ensure that the assumptions (benefits, costs, risks) therein contained remain valid. This along with making sure the proper stakeholders are involved greatly increases ensuring that the IT solution project maintains its value to the organization.
First, sorry for the tardiness of my posts. Between the holidays, coming back from the holidays, a cold, and a secret project (for now), I haven't had time to blog.. until now. My current focus has been a Facebook game application. Well it's still in the alpha phase, but I wanted to get the architecture up and running. There's nothing worse for an application development person than to finish your application, then find out you need to rewrite it (or worse) because of the architecture doesn't support it. Even without Zembly, setting up a Facebook application is pretty easy. Since I had most of the defaults already in, the only thing I need to do is to tell Facebook where my application resides. Since I don't have Zembly anymore, I have to put on my application development and network administrator hats on set up an application server.
Its good to see Cincinnati and Dayton area companies starting to embrace open source as an alternative to custom application development. As an IT Strategy consultant, I can say there is a place for both.
I have not one, but two JavaFX Kenai projects found 
Come on, come on, come on, come on now Touch me, babe! Can't you see that I am not afraid? ....... Yea, I have been listening to 
A couple of weeks ago, I made the trek to Columbus and attended the Ohio chapter meeting of 
Web application development is a must for Cincinnati and Dayton companies. We at STAR BASE, Inc. have written much lately about open source IT solutions. Since we have been on a roll with that, why stop now? 
Powered by Compendium Blogware