System Implementation Project Management |
Key Measures:
1.Before even looking at business requirements or spending much time on a project, make sure you know:
a.Who the executive sponsor is and obtain the following information directly from that sponsor:
i.Project intentions and scope
ii.What the project is NOT or what is out of scope
iii.Who the Customers are for the project. (many times, customers are internal to the organization)
iv.If a Return on Investment document has been created and what is expected of a ROI document. What areas of the business are returns expected?
v.Project Budget and how expenditures are approved
vi.Expected Project Success Factors
vii.That they want this project moving forward at the present time, if not, when is it to start
viii.Timeline expected for project completion
ix.Agreement to put companies resources on the project to get it done
x.Required project status and reporting
xi.Agreement on a communication plan to sponsors, customers and other impacted parties
xii.Agreement as to the assigned project manager and support from the sponsor that if there are problems with the project that require the executive sponsors attention, that the sponsor will extend support for obtaining the resolution
a.Who the executive sponsor is and obtain the following information directly from that sponsor:
i.Project intentions and scope
ii.What the project is NOT or what is out of scope
iii.Who the Customers are for the project. (many times, customers are internal to the organization)
iv.If a Return on Investment document has been created and what is expected of a ROI document. What areas of the business are returns expected?
v.Project Budget and how expenditures are approved
vi.Expected Project Success Factors
vii.That they want this project moving forward at the present time, if not, when is it to start
viii.Timeline expected for project completion
ix.Agreement to put companies resources on the project to get it done
x.Required project status and reporting
xi.Agreement on a communication plan to sponsors, customers and other impacted parties
xii.Agreement as to the assigned project manager and support from the sponsor that if there are problems with the project that require the executive sponsors attention, that the sponsor will extend support for obtaining the resolution
b.Then put all of that information in writing, generally
in some sort of project initiation document and then all project
leaders, sponsors and customers and CIO SIGN the document. I cannot
stress
how important this part is. I cannot stress how many times we have come the end of a project and at least one of these parties (sponsors, customers or CIO) state they never agreed to some portion of the documented information in the project initiation document. This is especially important for System Implementation projects as a lot of time can pass between the time the project got underway and the time the final product is delivered.
how important this part is. I cannot stress how many times we have come the end of a project and at least one of these parties (sponsors, customers or CIO) state they never agreed to some portion of the documented information in the project initiation document. This is especially important for System Implementation projects as a lot of time can pass between the time the project got underway and the time the final product is delivered.
2.Business Requirements
a.It is vitally important, before talking with any IT personnel (if the project involves internal IT which, if it is system implementation, it most likely will) or product vendors, that you take the time needed to adequately document all business requirements from all customers. Documenting business requirements should, at a minimum, involve going through the following steps:
i.Identifying the subject matter experts and project representatives from each part of the business that serve as your customers for the end result of the project.
1.Identify the current problem or need
2.Document current processes
3.Discuss what is not working about the process
4.Review results they would like to see to support the business and analysis they need to perform to manage the business
ii.In business requirements documentation, DO NOT spend time discussing what systems or technology will allow them do. Discuss what is needed for the business. Do not let your customers try to define a process around systems or technology. Technology is there to support the business, not to dictate how a business should be run. Dont worry, All the technical pieces will come together later.
iii.Document all the business requirements as discussed with all customer groups and subject matter experts. Be sure you specify the problems and needs, how it is hurting the business, what is needed, and how that will help the business. Be specific. This information will help you put together the ROI document to be sure the cost and expected benefits are in line with what the project sponsor(s) is expecting. Some project managers might disagree here and state that the ROI should be done before getting to the business requirements stage. However, I have always found new areas of investment (cost) and return on that investment present themselves when going through the business requirements discovery process.
System Implementation Project Management |
v.You will then match the business requirements to the scope that you created in the project initiation document, or change the scope, which would require an amendment to the project initiation document requiring new signatures. vi.Once the right set of requirements is documented and it lines up with project scope, then be sure to again have project sponsors, customers (remember, customers can be internal or external), and CIO acknowledging these are the business requirements, that the project is active and sponsored, and that they are in agreement with moving forward to the next project phases. This piece is especially important, as people tend to forget or say things like I never said that as you get further along in the project. You can always bring them back to the initial documentation and signatures.
If you do not get signatures, you are a sitting duck.
3.Now its time to figure out how you are going to deliver on these business requirements. This usually leads to a buy or build decision. That is, buy software from a vendor that specializes in the type of product needed, or build with internal IT personnel. The business requirements document is your basis for evaluating the buy or build decision. Do not stray; do not extend scope or budget, without going back through the sign-off process. If you are buying a product from a vendor, do the initial paring down process of determining top software products which match the business requirements.
4.Now that you have your top list of software contenders, have demonstrations performed by the vendors for your customer group(s). They can help cast the vote for the selected product. It is critical to get buy-in from your customers every step of the way.
Comments
Post a Comment