Project Implementation Plan

Need an information management project implementation plan and want practical suggestions and samples to ensure rapid project delivery?

A project management plan is a communications tool, which clearly sets expectations for all team members. It helps new team members quickly see who is involved with the project and helps minimize project delays due to miscommunication. It also helps other stakeholders know what is expected of them and when. Some organizations have very large IT departments and staff are assigned to numerous projects at one timeA project plan ensures that all team members know what they are expected to deliver, when it is required, who will accept the deliverable and how it will be approved. Why is it Important?

Imagine an architect planning a new building. The design is not complete but he already should know key things like what standards the design specifications should meet, what building codes will apply, how he will expect suppliers to communicate delays, etc. A project implementation plan is very similar. It is a road map and schedule needed to ensure timely completion of the project. What is included in an implementation plan? An information management project manager should create a project implementation plan to include the following:
y

Project objectives and goals specifies what the project is intended to achieveThis should be a re-statement of the objectives and goals described in the business case; Resource plan specifies roles and responsibilities for all information management jobs and how project team management is organized including: The expected level of effort required for each resource together with the cost and work schedule; and o Other project resources, such as team rooms, specialized software, licenses, and software project management tools, etc,
o

Project approach specifies the tasks and deliverables, project management methodologies and approach that will be utilized and how project documentation will be managed. The approach also describes any planned iterative development or prototyping methodology that might be adopted by the project team; A project management communication plan specifies how communication will be managed and who is responsible for communications; Risk management plan defines the process that will be followed to identify and resolve project risks; Configuration management plan identifies deliverables that will be included in formal configuration management, what configuration management tools will be used and what project management templates are required; Project quality management plan specifies plans to ensure deliverables comply with standards and best practices, including any review/checkpoints; Test plan specifies how quality assurance testing will be managed, who will be responsible for creating test cases, what software test tools will be required, and how project acceptance will be determined;

Requirements management plan and project management scope specifies how requirements will be reviewed and approved, what requirements management tools will be used and how the requirement traceability matrix will be maintained; Documentation management plan should specify the project management document review process and baseline procedures together with any other project documentation standards; Project management templates should provide a complete set of templates with hints and suggestions form completion; and Project scope management specifies the approach for ensuring that the project does not deviate from the project objectives and how scope creep will be addressed. Click here to see a sample project implementation plan template Click here to see a project management checklist

Project Team Management Resource Plan

Accountable for project team management for an information management project and want some practical time and cost saving suggestions? A resource plan is part of a project implementation plan and should list

all project roles and responsibilities, level of effort, and other project team resource requirements. Sounds easy! Information management projects have a small number of roles and responsibilities Lets put everyone in a room for three months and hope for the best. This approach has merit if the team is a self-contained unit responsible for producing project deliverables and turning them over to production with no support from other IT resources.

Unfortunately, we need to take off the rose colored glasses and look at reality. Project team management reality check! Many IT departments are very large, sometimes with two or three thousand employees/contractors and consulting staff. These resources are frequently geographically dispersed in different cities and/or in different countries. IT staff may be assigned to resource managers, who have responsibility for assigning them to projects. Others may be part of an IT resource pool and are assigned on a first come basis by a central resource planning system. In other words, if you want a data modeler for two weeks in September, you submit your request and you get the first person available. To ensure complete resource planning... Consider all of the extra resources that will be required to make a project successful. The following provides a sample of resources that may be considered for project team management:
y

Center of excellence staff may be required to participate in project deliverable reviews. These reviews may not require too much time but project delays will occur if they are a critical part of deliverable acceptance and no one is available or assigned; Legacy source system production support staff may be required to produce new interfaces and push" data for your solutionFailure to consider them early will cause delays while your team waits; Vendor supplied support staff may be required to help extract data from CRM and ERP applications. Obtaining this support may involve creating statements of work and getting financial and technical approvalAll if this takes time and must be considered in the resource plan; An independent QA team may be required and the plan should include provision for QA management time and ramp-up learning; Production support staff may be required to help execute tests during QA testingIt is important that this time be included in the plan; and There are numerous other resources that may be required to ensure project success--They all must be included in the resource plan.

To provide resource flexibility, consider... Other resource options, if permitted, such as:

y y y y y

Individual contract employee support--Is it practical to engage them for short time periods? Consulting firm "time and material" contracts; Consulting firm "fixed price" contracts; Off-shore development; Part-time contractor support--Do you really need someone full-time or can some work be handled by 10-200 hours per week on a contract basis?

How are project team management resource plans created? This depends upon the organization and the project planning tools. In some places, it is mandatory that the project plan be included in a central time reporting system. Resources are allocated based on your projections and their availability. Time cannot be reported to a project unless a task has been assigned to a resource. This approach has merit but must be carefully managed to ensure that staff allocations are not too restrictive. In other words, dont plan a lot of very short (e.g. 5 hour tasks)...but dont plan any three-month tasks either. What are other critical resources? Plan early to obtain other needed resources such as:
y y y y

Team rooms with white-boards (and markers); Overhead projectors; Software test tools; Specialized development software and licenses and/or access for all team members. Failure to do this early may case delays as the team waits to gain access to critical tools.

To minimize project expense, consider

y

Do you need all team members at every weekly status meeting or will status reports suffice for the peripheral resources (I have seen many projects with 30-40 team members faithfully attending meetings and reporting time when their actual contribution may not be required for three to four months downstream); and Make everyone aware of the resource estimates and expectations. Review, and secure approval for all estimates, with individual resource managers. Try to avoid the lone contractor who, in good faith, spends three weeks developing a solution that was only expected to take three days.

Summary... Project team management is a critical part of a successful information management project and a good resource plan should list all project roles and responsibilities, level of effort, and other

project team resource requirements. This planning must be completed early in the project and communicated clearly to all project team members to set expectations.

Software Project Management Tools

Need software project management tools for an information management project and want some practical suggestions to ensure rapid project delivery? Information management projects require the same set of tools that most

other projects require with some specific exceptions. The following identifies some of the software project management tools I have used on projects together with some things you might want to consider early in the project. Project planning Project scheduling tools such as Microsoft Project or Omni Plan are needed and licenses are expensive. Consider...
y

Can you publish the project schedule, in pdf format, in a central repository, to minimize the number of copies needed; and

Can you use other tools like Microsoft Outlook or Ical to assign tasks and follow-up with team members?

Project reporting Many organizations have a link from the project schedule to a central time reporting system. The project plan is uploaded to the time reporting system and tasks are assigned to team members by the time reporting system. Some thoughts
y y y y y

All team members will need to be assigned to your project in the time reporting tool; Access request may be required; You may need to be attentive to assigning project tasks as some systems will not allow team members to report time without assigned tasks; Some contractor payments are tied to completion and approval of automated time reportingthis requires attention to the approval process to avoid delayed payments; and Time reporting orientation might be a good topic for the project kick-off meeting.

Requirements management software project management tools Many organizations use a requirements management tool like IBM Rational RequisitePro. These tools are very powerful and offer many features that may not be required for your project. Consider...
y y y y y

An administrator may be required to tailor the tool for your use and to maintain user access (most team members will need read access); Team orientation will be required and some one will need to prepare this (perhaps an external project team resource can help?); How will requirements traceability be handled? (This should be tailored for your specific project); What is the base-line process? How to ensure requirements are not changed after base line.

If you dont have a requirements management tool, you will need some method of creating the requirements and base-lining them. Consider posting a pdf version of the base-lined requirements in a team folder. Data modeling software project management tools Data modelers will need a data-modeling tool e.g. Oracle Designer, CA Allusion ERwin Data Modeler, or Sybase Power Designer, and perhaps access to a central repository. Consider...
y y y

Access request for the repository; Licenses (these are expensive); and Training, if team members are not familiar with the specific tool set.

Data Analysts will need some form of data flow diagram and data movement modeling tool like Microsoft Visio. Licenses may be required. Data profiling tools Data analysts will need a tool for data quality analysis and data profiling. Sometimes, the ETL tool can perform this task. Consider...
y y y

What tools will be used and who will use them? Source system access request to conduct the data profiling (or make arrangements to get sample data moved to a location where your team has access); and This is usually a one-time effortcan a shared license work?

Data movement tools You will need ETL tools and licenses for each development member. You will probably need to request access to the code repository. Testing tools Many organizations use a testing tool like IBM Rational ClearQuest or Mercury Test Director. These tools are very powerful and offer many features that may not be required by your project. Consider...
y y y

An administrator may be required to tailor the tool for your use and to maintain user access (most team members will need read access); Training (basic training plus project specific training); and If these tools can handle defect reporting.

Configuration management tools Does the organization use a software configuration management tool such as Serena ChangeMan or a configuration management database? Consider...
y y

Access for appropriate development team members; and Basic training.

Documentation management Many organizations use a common document management system such as Microsoft SharePoint. Consider...
y y y y

Folder structure set-up (who will handle this?); Access request for all team members; A project team administrator; and Can it be accessed off-site?

If you plan to use a shared folder for all documentationConsider...

y y y y

Folder structure; Can it be accessed off-site? How to lock documents after they are base-lined; and How to avoid documentation proliferation.

Communications Many project teams today are geographically dispersed with some team members working remote. Email is not always the best means of communications and team members will need remote access to project resources. Consider...
y y y y y

Conference calling lines; Instant messaging; Collaborative desktop sharing software for presentations and deliverable review; Firewall limitations that may prevent instant messaging and desktop sharing; and Web-based services like Web Ex, or Adobe Acrobat that will work with your firewalls.

Summary... Project resources and software project management tools are required to ensure successful information management projects. It is critical that these be identified early in the project management plan together with any training required. Its a lot easier to get approval for software project management tools at the project planning stage than to have to justify expenses part way thru the project.

What is Iterative Development?

Need iterative development for an information management project and want some practical suggestions to ensure rapid project delivery? Iterative development is software development methodology that breaks

a project up into a series of manageable sub-components, or iterations. Each iteration is then treated like a small project with its own design, development and testing steps. Iterations are time-boxed. This implies careful planning to ensure that the planned work can actually be completed in the allotted time frame. What is waterfall development? Waterfall development is a software development methodology that relies on completing one project phase and obtaining sign-off/approval before proceeding to the next phase. For example, the requirements analysis phase is completed and approved before any architecture and design commences, the architecture and design phase is completed before any software development

commences, and all development is completed before testing starts. What are the benefits of iterations? Iterative development can really reduce software development timeIt helps the team maintain focus and it keeps everyone fully engaged thru-out the iteration. What are some things to avoid?
y

I have seen some iterative development projects include data modeling as part of the development process and have found this to be less effective than completing the logical data model prior to commencing iterations; and Information management projects are data centric by nature and I believe that the overall architecture and design framework should be robust before commencing any iterative development.

What are good candidate iterations? Information management projects typically involve developing software to:
y y y y y

Extract data from source systems and move it to staging areas for data cleansing and transformation; Integrate and transform data per business rules; Load it into a data warehouse (or perhaps operational data store); Extract it from the data warehouse and load it into a data mart; and Develop business intelligence software to build pre-defined reports and analytical capabilities.

There are several possibilities for iterative development:

y

y y y y

The interfaces may be split into iterationsI like this approach because we can parcel out some of the less complex logic and have it completed as a foundation for subsequent transformation work; The transformation and integration of data can also be split up into iterations; Data warehouse loading might be split up into iterations; Extract and load to data mart could be a series of iterations; and Any of the business intelligence/reporting development might be split up as a subcomponent.

You might also consider a combination of interfaces, or source data, and treat the entire combination as an iterationIn this case, the development runs end-to-end or at least to the data warehouse. How long should iteration take?

Good question! I have seen some iterations take 3-4 months and, in my opinion, these are not truly achieving the objectives of rapid development. I like to use a two-week iteration and include final design, development and testing in this time frame. I have seen others use the two weeks for design/development and leave the testing for a third week. In either case, I believe each iteration should be completed in a two to three week window. Can we have multiple iterations at one time? YesThere is no real need to complete one before another although in reality, with some projects, you will find that this might make more sense. How much iteration can we run in parallel? I suppose, in theory, that you can run as many iterations as you wantas long as you have sufficient resources. In practice, I have found that there is a lot of technical coordination required and that two or three parallel iterations provide the best of both worlds. It keeps a small team focused on objectives, it is manageable, and it has a high probability of rapid delivery without slippage. Things to consider...
y y y

Iterations are time-boxed so anything that does not get finished in one iteration will need to be added to a subsequent iteration; Iteration planning is critical so that we know the objectives before development commences; and Dont try to run too much parallel iteration.

What happens during a typical iteration? I try to keep the entire team together as much as possible. Assuming a Monday start, the following schedule can be considered: Week 1:
y

Monday o Iteration kick-off and review of objectives and requirements; o Complete source-to-target mapping and finalize business transformation rules; and o Finalize test data acquisition approach.

y y

Tuesdayfinalize appropriate design specifications. Wednesday o Review/approve design specifications; o Commence code development; o Prepare test cases and test scripts; o Commence test data acquisition; and o Develop data structures in appropriate environments.

Week 2:
y

Wednesday noon o Finalize all coding; and o Complete unit testing and code review. Thursday-finalize all testing and resolve any defects. Friday
o

y y

Close iteration and decide what, if anything, needs to be carried over to another iteration; and o Conduct lessons learned.

Summary... Iterative development breaks a project up into a series of manageable sub-components or iterations. Each component is treated like a self-contained mini project and requires strong technical leadership and direction to ensure rapid development and successful implementation.

What is a Prototyping Methodology?

Need prototyping methodology for an information management project and want some practical suggestions to ensure rapid project delivery? A prototyping methodology is a software development process which

allows developers to create portions of the solution to demonstrate functionality and make needed refinements before developing the final solution. Think of the annual Detroit car show where some automakers will introduce a concept car or prototype. Depending upon interest, it may eventually become a full-scale production vehicle or

it may be modified based on consumer reaction. Software prototyping Software prototyping is somewhat similar. It produces a throw-away solution that is deigned for the sole purpose of verifying user functionality and for demonstrating capability. It is an excellent way for the development team to confirm understanding of the requirements and ensure that the proposed solution is consistent with business expectations. When should we use it? This methodology works very well with online transaction processing systems, which usually interact. It also works well with web-based development and can very quickly help confirm page navigation and other user interaction requirements. What about business intelligence prototypes? A prototyping methodology is very useful for confirming business intelligence analytic requirements. End users do not usually think in terms of facts and dimensions. They are frequently not exposed to the capabilities of business intelligence software and the power of the tools. I remember one project where the user community was moving from obsolete technology (which produced paper reports) to a Business Objects XI platform (Which was the company standard technology). They really had no idea how to express requirements other than to say, "Give us what we have today". We tried vendor provided product demonstrations, which helped a lot. However, it was only when we created a working prototype solution, with their data, that users were able to work with the tool and see its capabilities. Project requirements were not actually changed on this project but we saved a lot of churn that might have occurred during design/development. Thanks to the prototype, the users already knew how they wanted certain things like folder structures, and naming conventions. The user community also became involved so they took more ownership for requirements as they gained confidence working with their prototype. Did you say throwaway? Yes, I didThe basic premise of prototype development is the software should not be used for productionThat is not the purpose of prototype development. I remember another project where we were contracted to design and develop a prototype

solutionWe were expected to use the prototype to flesh-out requirements. The project was a recognized international success. We concluded the project with a set of recommendations that we had discovered while using the solution (We had discovered one fairly significant flaw that we felt should be addressed in a full production solution). Did you guess what happened? Project funding was put on-hold for a while but one of the business users decided to implement the prototype solution anywayThe solution was more robust than most prototypes but it still had the flaw. This particular user group knew about the issue and had a good work-around. Unfortunately, these types of solutions have a habit of outlasting people who know about the work-around. Some things to consider
y y y y

Prototype methodology is a very useful way of confirming business intelligence analytics and reporting requirements; The prototype solution must be considered throw-away; Plan the time and effort as part of the requirements analysis phase and possibly the development phase; and It has limited use for demonstrating data storage and data movement portions of the solution.

Before you return, remember... A prototyping methodology is a software development process which allows developers to create portions of the solution to demonstrate functionality and make needed refinements before developing the final solution. This technique can save considerable development time by reducing re-work as users see the product for the first time.

Project Management Communication Communications Plan

Need project management communication for an information management project and want some practical suggestions to ensure rapid project delivery? A communications plan specifies how communications will be maintained

among and between project team members. Why is this important? This key document ensures that all stakeholders are aware of the communication channels and helps avoid confusion and misunderstanding. A typical case of bad communications A quality assurance test run has been running for 6 hours and the normal duration is 30 minutesthe production support specialist sends an email to all developers at 2:00 AM asking

for help. One dedicated developer, who is not on the release team, makes a good suggestion, and the job is aborted and re-started. Unfortunately, that was not the correct answer because the job was actually expected to take 10 hours because of specialized processing required for the test. The impact of this bad, but well-intentioned, communicationTwo days lost while restoring the data base environment and re-starting all processes. In this case, the correct communications channel should have been direct to the release manager who knew that the job would run at least ten hours. This type of communication happens all too frequently and results in considerable project loss A well planned, and well managed, communication plan will prevent things like that from happening to you. What is normally included in a project management communication plan? Projects normally have on-going communications such as:
y y y y

Status reporting; Project schedule updates; Financial updates; and Risk and issue reporting.

They also have one-time or infrequent communications such as:

y y y y

Project kick-off meetings; Phase kick-off; Lessons learned; and Others...etc.

Things to consider... I have found that the following are frequently forgotten in project communication:
y y y y y y

Policy, standards & best practices, to ensure everyone is aware of expectations; New team member on-boarding, to ensure everyone ramps up quickly and is aware of project objectives (how many times do we promise to do this? Defect management reporting; Change management communications; QA test reporting; and Release management communications.

What should the plan include? The following example shows what is expected in a communications plan. Who Name and role of person who will receive the communication. What Purpose for communicating (i.e. Project Status update, financial status update, Review Issues) How Method of communicating (i.e. Status Report, PowerPoint presentation) When Owner

Daily, Person who will Weekly, create the Monthly, communications Quarterly

Summary.. A communications plan specifies how project management communication will be maintained among and between project team members. This key document ensures that all stakeholders are aware of the communication channels and helps avoid confusion and misunderstanding.

What is a Risk Management Plan?

Need a risk management plan for an information management project and want some practical suggestions to ensure rapid project delivery? A risk management plan defines the process that will be followed to

identify and resolve project risks. What is a risk? Risks are events, which, if they occur, may have a positive or negative impact on the project objectives What is an issue? Issues are risk events or risks, which have occurred, and require resolution to minimize the impact to project objectives. Suppose you are planning a vacation. You are going to fly to the west coast, rent a car for two weeks, travel a bit and then return. You heard that your airline might go on strike. This is a risk! You know that it might happen and you now have a chance to mitigate the risk. You might decide to minimize the risk by investigating train schedules, or other airlines, or car rentals. If a strike occurs, you can still go and achieve your objectives of having a good vacation. Now suppose you fly to the west coast as planned and the airline goes on strike before you can return. You now have an issue that you must resolve. So how do we manage risk? A good risk manager will be constantly aware of project risks that might occur and will attempt to have a mitigation strategy ready in the event that the risk becomes an issue. What should we document in a risk management plan?
y

Which member of the team will manage and update issues and risks;

y y y

The frequency of which risks and issues will be reviewed (at least once per phase); Where the risk & issues Log will be stored; and The escalation path for resolving a risk.

The risk manager will ensure that all risks are reviewed and mitigated before they become an issue What are risk/issue categories? Information management projects usually classify risks and issues in the following categories: Technical risks/issues include things like:
y y y

New technology, the project team learning curve may be longer than expected; Technology changes, the solution is planned for one set of technology and it changes part way thru the project; and Process, the team is not fully versed in the process or it may change causing issues.

Project management risks/issues include thinks like:

y y y y y

Resource allocation, a project resource is over committed and may miss milestones; Scope change, may require project plan change and losing committed resources to other projects; Requirements traceability, a missed requirement was only discovered during development or QA testing; Methodology, business owner and IT sponsor cannot agree on managed exceptions to approved software development lifecycle; Tools, a critical tool may be down for an extended period, e.g. documentation repository, metadata repository, or access was not requested in time and there is a waiting period to have the access request approved; and Team experience, lack of experience on process, methodology or tools may cause delays.

Organizational, risks/issues include things like:

y y y

Financial projections and level of effort, team may provide inaccurate estimates which impact budget; Project independence, other projects may get higher priority for key resources leaving a project gap; and Economy, may dictate reduced resource levels.

External, risks/issues include things like:

y y y

Contractors may not produce as expected and contractor change is required part way thru the project; Regulatory changes may change priorities and cause rework; and Vendor-vendor relations may impact project communications.

Before you return, remember

y y

Risks are events, which, if they occur, may have a positive or negative impact on the project objectives; and Issues are risk events or risks, which have occurred and require resolution to minimize the impact to project objectives.

A good risk management plan will ensure that all risks are reviewed and mitigated before they become an issue.

What is a Configuration Management Plan?

Need a configuration management plan for an information management project and want some practical suggestions to ensure rapid project delivery? Configuration management (CM) Configuration management is a set of processes and procedures required to ensure that all hardware and software components in production environments are clearly identified and are not modified without some authorized process. For information management purposes configuration management applies to all of the software code, documentation, test results and other deliverables that are produced during an information management project. What standards and best practices are required?
y

All components should have a standard naming convention and all components should comply to the standard naming convention; A CM database should be established to record the name of the configuration component and the version; SCM tools and platforms should specify the tool/platform, version and function of each tool; Configuration identification should be specified including:
o

Work product identification and disposition should specify project work products (deliverables), how they will be controlled, where they will be stored and what tool will be used; Naming and identification scheme should specify each work product (deliverable) and the naming scheme required; Baseline creation process should specify how a baseline configuration will be determined; Labels should specify the label naming conventions

o y y

Branching/merging should specify how branching/merging will be handled; Managing configuration items should specify how configuration items will be stored in:

o o y

Software work product storage; and Repository access and control

Development disaster prevention and recovery should specify processes to be followed in event of disaster or operational failure Configuration control should specify the control procedure for change management; Configuration status accounting should specify the types of status accounting reports required; Configuration audits should specify audit requirements, audit schedule and auditors name; Configuration reporting and tracking should specify the reporting requirement; Subcontractor or vendor control should specify configuration management requirements for subcontractor and vendor work; and SCM metrics should specify metrics and analytics reporting requirements

y y

y y

Accountability Accountabilities for each key role involved in CM should be defined and communicated to all stakeholders. Summary... A configuration management plan is a vital component of information management and requires that standards or best practices be documented and communicated to all stakeholders

Project Quality Management Quality Assurance Plan

Need to ensure project quality management for an information management project and want some practical suggestions to ensure rapid project delivery? A quality assurance plan is part of a project implementation plan and

describes the review/checkpoint process that will be followed to ensure that the management information solution satisfies requirements and complies with standards and best practices. The following identifies some key things I like to include in a quality assurance plan Depending on the size of the project; these might be more (or less) elaborate. Data requirements Who is responsible for ensuring that data requirements and the logical data model complies with data model standards and how will this happen?

Is a peer review part of the process?

Is there a checklist of items that must be completed?

Are business owners and/or data stewards included in a review?

Is there a structure and design center of excellence that should be included in a review? Data movement requirements Who is responsible for ensuring that the data movement model complies with standards and how will this happen?

Are source system experts involved in a review?

Is there a checklist of items that must be completed?

Are data stewards or other subject matter experts included in a review?

Is there a data movement center of excellence that should be included in a review?

Is a formal review of the source to target mapping documents included in the project quality management plan? Information usage requirements

Is there a checklist of items that must be completed for information usage requirements?

Are business owners and/or data stewards included in a review?

Is a peer review of the dimensional model review included in the QA plan?

Is a use feedback session part of the project quality management plan?

Is a formal sign-off part of the process? Functional and non-functional requirements

Who has ownership for certifying that functional and non-functional requirements are in sufficient detail to commence architecture and design?

Are the business owner and data architect included in a formal review? Requirements management plan

What is the process to ensure quality of the requirements management plan?

Are review/checkpoints and a checklist for completing requirements traceability and satisfaction of requirements included in the quality assurance plan?

What is the process to prevent requirements changing without approval? Information management requirements specification

What is the review/checkpoint for the information management requirements specification?

Is it a big-bang review or are many mini-reviews scheduled?

Is there a formal sign-off process?

What is the process for ensuring that changes do not occur, after base line, without a change request/approval process? Architecture document

Who is responsible for ensuring quality of the architecture document?

What is the review/checkpoint process?

Is there a pre-defined quality checklist? Database design Who is responsible for ensuring that physical data model complies with data model standards?

Is a peer review part of the process?

Is there a checklist of items that must be completed?

Is the DBA involved in the review?

Is there a structure and design center of excellence that should be included in a review?

Design specifications

Who is responsible for ensuring quality of the design specifications?

Who is involved with reviews?

Is there a pre-defined quality checklist?

What is the requirements traceability process? Code reviews

Who is responsible for ensuring quality of the code?

Is a formal code review part of the quality assurance plan?

Does the project schedule have sufficient time allocated for re-work if necessary?

Is there a pre-defined quality checklist? Test plan

Who is responsible for ensuring quality of the test cases and test scripts?

Are quality assurance test cases based on design specifications?

Are architects and designers involved in reviews?

Are user acceptance test cases and test scripts built from requirements specifications?

What process will ensure that we are not testing for things that are not requirements?

What process will ensure that we test for all requirements? Project phase quality The project quality management plan should also document the process for documentation review/sign-off and approval for the end of each phaseIt should identify phase entrance/exit criteria and the process that will be followed to ensure criteria have been met. How can we reduce project time required for reviews? Consider some form of project collaboration tool such as Net Meeting, WebEx, Acrobat.com, Instant Messenger, etc--This way, everyone involved with the review can work at their desk and focus on the specific items being reviewed--I have found it a lot easier for team members to follow review items on a computer screen than on hard-copy material. Summary... Project quality management is an ongoing process. The quality assurance plan is part of a project implementation plan and describes the review/checkpoint process that will be followed to ensure that the management information solution satisfies requirements and complies with standards and best practices. This planning must be completed early in the project and sufficient time should be allocated in the project schedule for the reviews.

What is a Test Plan?

Need a test plan for an information management project and want practical suggestions to ensure rapid project delivery? A plan is a communications tool, which clearly sets testing expectations for all team members.

Think of it as a mini-project plan which documents test objectives, roles and responsibilities, test deliverables, test tasks, defect reporting requirements, entrance criteria, that should be met before formal testing commences; and the exit criteria that must be met before testing can be considered complete. It helps new team members quickly see who is involved with the testing and helps minimize project delays due to miscommunication. Why is it important? Suppose you have just had a new house built. Everything looks good to you and you move in.

Come winter, your water freezes, your electrical service short-circuits when you turn on the Christmas tree lights and try to cook the turkey at the same time, and snow blows thru cracks in the window frames. This probably will never occur because we have building codes, regulations and inspections to ensure that construction meets standard. What about information management standards? The information management framework established project deliverable standards and best practices. The quality assurance plan ensures that design and development meets standards. However, how do we know everything works? We need to validate that the solution matches specification and meets requirements. This is where a good test plan helps. What is included in a test plan? A test plan should include the following:
y

Test objectives, should summarize project objectives, test objectives, scope and roles and responsibilities; Test strategy, should refer to the requirements acceptance criteria, that were developed as part of the requirements definition phase, and the test environments that will be used; Test plan, should list the scope of each test, including entrance criteria, how test cases will be prepared, what test data will be used, what test scripts are required, who will execute test scripts, how defects will be managed, how test results will be managed, and test exit criteria; Test data strategy, should list the overall approach for creating test data. Try not to use large volumes of data for unit, system, integration, regression and quality assurance testing.

You can adequately complete these tests with a sub-set of data. Failure to do this will add significantly to the test period and will not add additional benefit. The extra time it takes to create a complete set of test data early in the project will be paid back many times by reducing the time to back-up/restore data during testing;
y y

Test deliverables should specify what will be produced; Resource plan should list all project roles and responsibilities, level of effort, and other test resource requirements;

Training considerations, should list any training that might be required so the test team can complete testing; and Test schedule, should identify a test schedule that clearly defines when all testing is expected to occurThis schedule may be included in the project schedule. Click here to see a sample test plan template

What types of testing are included in a test plan?

y

Unit testing should focus on testing individual modules to ensure that they perform to specification, handle all exceptions as expected, and produce the appropriate alerts to satisfy error handling; Integration testing should focus on testing a set of components to ensure that it performs to specification; QA testing should focus on testing a set of components to ensure that they meets requirements; and User acceptance testing (UAT) should focus on testing a set of requirements to ensure that they meet user expectations.

What information management technical testing is required?

y

System and volume tests to confirm that the system is operating correctly and can handle the required data volumes; Reconciliation tests to manually confirm the validity of data; Regression testing to ensure that the new software does not cause problems with existing software; Performance testing to ensure that data can be loaded in the available load window; Security testing; Load manager testing; Warehouse manager testing; and Infrastructure and operations component testing.

y y

y y y y y

Summary... A test plan is a communications tool, which clearly sets testing expectations for all team

members. It is important to complete the plan early in the project and manage it carefully to ensure on time, within budget project delivery. It is also important to recognize that the technical team should perform much of the technical testing.

Project Management Scope Requirements Management Plan

Accountable for project management scope for an information management project and want some practical suggestions to ensure rapid project delivery? A requirements management plan describes how requirements will be

managed throughout a project lifecycle. It ensures that the project schedule and budget are not compromised by unauthorized requirement changes and, it ensures that all requirements are delivered as planned. Why is this important? This is vitalImagine you are having a new house builtAs it is being constructed, you see how nice it would be to have the master bedroom face east so it can get the morning sun, instead of west as planned. Now think of the impactWell, its obvious that there would be a big impact.

Now think of the smaller thingsA carpenter decides to install an extra cabinet because it will look nice, a plumber decides that an extra sink will look good in the master bathroom, and an electrician forgets to install a security light at the back door. Each of these items can add time and cost to the house and you will eventually have to pay. The same thing can happen with an information management project. Requirements may be defined and approved at the beginning of the project but if they are not managed carefully, changes may be introduced that will cause delays and additional costs. Project management scope and a requirements management plan are designed to prevent this. What is included in a requirements management plan? The following are normally included is a good plan:
y

Resource plan, identifies roles and responsibilities and any other resources required for requirement management; Requirements gathering, describes the approach that will be used to collect all requirements and identifies key participants; Baseline process describes the process that will be followed to ensure that requirements are reviewed, approved and base-lined. (After a requirement is base-lined, it should not be changed without a formal change request); Configuration management, specifies the unique numbering scheme or naming convention that will be used to ensure that each requirement is uniquely identified; Change management, specifies the process required to request, and approve, requirement changes; Communications plan, specifies what mechanisms will be used to communicate changes in requirements or other issues such as missing requirements traceability; and Satisfaction of requirements (requirements traceability matrix) specifies the process required to ensure that all requirements are addressed during architecture and design, build and test, and that no additional requirements were added.

This also should identify the process for specifying requirements acceptance criteria and the process that will ensure that acceptance criteria have been met. Click here to see a sample requirements management plan

How does a project management scope plan help deliver project faster? The document defines the plan that must be followed. It provides clear direction to all team members and eliminates project time loss e.g. if the technical team thinks a requirement was missed, the plan clearly states:
y y

If its not a requirement, dont build it; and If is should be a requirement, follow the change request process, and only build it if approved.

Summary... A project management scope and a requirements management plan describe how requirements will be managed throughout a project lifecycle. It ensures that the project schedule and budget are not compromised by unauthorized requirement changes and, it ensures that all requirements are delivered as planned. A well-managed plan will minimize time delays and additional project costs.

Documentation Standards
Need documentation standards for an information management project and want some practical suggestions to ensure rapid project delivery?

I have sometimes seen project documentation described as artifacts. Artifact is defined by the Oxford Dictionary as a product of human art or workmanship or a product of pre-historic or aboriginal workmanship as distinguished from a similar object naturally made Umm...Perhaps the people who call project documents artifacts" have been working on the same project so long that documentation is ancient at project close? Project documentation standards, its all about communications Think of the days when we had two or three person teams and the user was part of the team Communication was easy and we had less need for a lot of formal documentation standards.

Now, think of an IT shop with several thousand people scattered around the globe. Project documentation is designed to bridge the communications gap. It is critical to the success of any project and needs to be managed to ensure that each piece of documentation meets its objectives. The following describes some of the key documentation standards required to ensure project success. Business Case This important document is essentially a contract between the business owner, who is paying for the project, and the IT departments, who will develop, implement and operate the solution. Approval of the business case signifies that:
y y y

The business owner agrees with the project approach and commits to provide the resources; The IT department commits to develop the solution based on the approach, cost and schedule specified in the business case; and Project planning can commence.

Project plan This builds on the business case and is an agreement between the project manager, the IT owner and business owner. It provides more planning information than the business case. Approval of the project plan signifies that:
y

y y

The project manager commits to deliver a solution, that will meet business case objectives, with the resources, management approach and schedule specified in the project plan; The IT owner and business owner agree to the approach and schedule and commit to provide the resources specified in the project plan; and Requirements analysis can commence.

Requirements definition The project manager uses the requirements specification to update the project plan and schedule. If the expected cost or schedule is substantially different than the business case cost projections, then the requirements need to be reviewed to ensure that they are really in scope. This is one of the most critical project documentation components. If the financial projections are significantly different from the business case, then the business case may need to be updated and approved, or, the requirements may need to be down-sized. When the requirements are documented and approved, the architecture and design/development team should be able to commence work without having to ask a many business related questions.

The requirements specification is an agreement between the end users, the business owner, the IT owner and the project manager. Approval of the requirements specification signifies that:
y

y y y y y y

The end users and business owner agree that the document specifies all structure and design, data movement, security, data quality, information usage, service level and functional requirements; The operations/production support team agrees that the document specifies all system, or non-functional requirements, needed to implement the solution; The business owner and operations/production support owner commits to accept the solution based on the acceptance criteria specified in the requirements specification; The technical lead agrees that the requirements specification provides sufficient detail to commence architecture and design; The test lead agrees that the requirement specification provides sufficient detail to create quality assurance and user acceptance test cases; Architecture and design can commence; and Quality assurance test case preparation can commence.

Architecture and design The Architecture document is another key component of project documentation standards. It serves as a communications link between the architecture and design team, the requirements analysis team and the user team. This critical document is the last chance to make modifications to the project schedule and/or cost. An approved architecture document is the basis for development work. Any changes after this is approved have to be treated as a change request because they are not included in the approved project plan. Approval of the architecture document signifies that:
y y y

The business owner, IT owner, project manager and technical lead agree on the solution; The IT owner commits to obtain any architecture components specified in the architecture documents; and Details design specification can commence.

Design specifications documentation standards These critical documents serve as a communications link between the design team, the development team and the integration test team. Approval of the design specifications signifies that:
y y y y y y

The technical lead agrees with the technical design; The requirements analysis team agrees that the design accounts for all requirements; The development team commits to develop code to meet specification; The integration test lead agrees that the design specification provides sufficient detail to create integration test cases; Development can commence; and Integration test case preparation can commence.

Unit test results Individual developers complete unit testing and unit test results demonstrate that code performs to specification. Unit test results form part of the code review. Approval of unit test results signifies that the designer agrees that:
y y y

Code was developed to standards and best practices; Code meets specifications; and System/integration testing can commence

Test plan documentation standards The test plan is vital. It is an agreement between the business owner, the IT owner, the project manager and the technical lead. Approval of the test plan signifies that:
y y y y

The technical lead agrees to the test approach and commits that expected results of integration test cases confirm the solution meets architecture and design specification; The test team commits that expected results of quality assurance testing confirm the solution meets requirement specifications; The operations/production support owner commits that expected results of non-functional testing confirm the solution meets non-functional requirement specifications; and The business owner agrees to the test approach and commits that expected results of user acceptance tests confirm the solution meets business objectives stated in the business case

User acceptance test exit criteria This document is part of the test plan and serves as formal confirmation that testing is complete. Approval of the exit criteria signifies that all stakeholders agree that the solution is ready to move to production. Release plan The release plan serves as a communications link between the project team and the production support team. It identifies each configuration item that will move into the production environment. It also includes all of the documentation needed to maintain and operate the solution. It is a commitment between the release manager, the IT owner and the operations/production support team. Approval of the release plan signifies:
y y y

The technical lead certifies that the configuration items included in the release package are the same set of configuration items that passed final acceptance test; The operations/production support owner commits to provide the resources specified in the release plan; The release manager commits to test the release process as specified in the release plan;

y y y

The operations/production support owner commits to accept the solution upon completion of release acceptance criteria; The IT owner commits to provide post production support as specified in the release plan; and The business owner commits to accept the solution and close the project upon completion of release acceptance criteria.

Summary Documentation standards ensure effective communication among and between project team members. Each piece of documentation is designed for a specific purpose. Project documentation needs to be managed to ensure that each piece of documentation meets objectives. Tight control of this process will reduce project time loss due to miscommunication.

Project Management Templates

Need project management templates for an information management project and want some practical suggestions to ensure rapid project delivery? Think of the days when we had two or three person teams and the user

was part of the team. Communication was easy and we had less need for a lot of formal documentation standards. Now, think of an IT shop with several thousand people scattered around the globe. Project

documentation is designed to bridge the communications gap. It is critical to the success of any project and needs to be managed to ensure that each piece of documentation meets its objectives. What documentation standards are required? The following documents and checkpoint processes are required to support an information management project management framework.
y y y y y y y y y y y y y y y

Information Management Plan; Business case; Business case analysis checkpoint; Information management requirement specifications; Requirements management plan; Project implementation plan; Configuration management plan; Quality assurance plan; Test plan; Planning and analysis checkpoint; Information management architecture; Architecture & design phase checkpoint; Design specifications; Release plan; and Change management plan

Summary Documentation standards ensure effective communication among and between project team members. Each piece of documentation is designed for a specific purpose. Project documentation needs to be managed to ensure that each piece of documentation meets objectives. Tight control of this process will reduce project time loss due to miscommunications.

Project Scope Management

Need project scope management for an information management project and want some practical suggestions to ensure rapid project delivery? The objective of project scope management is to ensure that a project

delivers everything that is in scope and does not deliver things that are out of scope. Sounds easy--Just dont build things that are out of scope! We all wish it were that easy. Information management project teams are comprised of highly skilled individuals who frequently see things that they think should be improved. These wellintentioned additions can quickly add up in cost and time. What do we need to manage scope? The business case is the starting point. It lists project objectives and scope. Each objective should also identify a means of measurement.

Suppose one project objective is stated as improve performance, and a measurement is stated, as ad-hoc report requests must be satisfied within 1 minute of submission instead of the current 5 minutes. The objective might be a little vague but we know how its going to be measured so we are OK. What can go wrong? Suppose we are loading the data mart, which will satisfy the ad-hoc request. We know the load will finish at 5:00 AM and that the users will never use it before 8:00 AM. We also know it will return results within 1 minute. Now imagine we have an innovative developer who decides to improve the load performance so that the load will finish at 1:00 AM. He develops temporary database structures, ETL routines and other code. Sure enough, the load does finish at 1:00 AM. Awesome! Is this a good idea? Perhaps, but we need to look at the bigger picture. The objective was to improve reporting performance and the code already did thatThe extra code that was developed to improve load performance was not really needed. It has introduced new routines that need to be maintained, new processes that need operational instructions, new data base structures that may need additional DBA support and new functionality that should be tested. (Which involves creating test cases, test data and test scripts). The developers thinks they have an excellent solution but the project bears the cost of added scope. It does not take too many of these great ideas to add up to project delays. How do we manage scope? Project scope management is a key component of project management. The following items should be considered:
y y y y y y

The business case needs to clearly state objectives; Each objective must define a measurement that will ensure the objective has been achieved; Each requirement needs to tie back to a business case objective; Each requirement must specify acceptance criteria; Upon approval of the requirements specification, no requirement should be changed without an approved change requestEven if its just a wording clarification; Each requirement must be traced thru the architecture and design, development and test phase to ensure that: o A design specification satisfies the requirement; and o A test case specification tests the requirement.

Thats not too difficult, what else do we need? Project scope management requires attention to detail. We know that we should not change requirements without an approved change request but what about other project documentation. Once project documentation is approved, it should not be changed without an approved change request.
y

If a developer finds issues with a design specification, a change request is required before it can be updated. It may be a defect in the design specification or it may be a defect in the requirementThis can only be determined thru impact analysis. If the design specification needs to be changed, then possibly a new integration test case and test data are required. It we have a requirement defect, then perhaps we also need to change the quality assurance test cases and test data.

How do we ensure we dont deliver more than whats in scope?

y y y

A good requirements traceability process will help ensure that we delivery everything that was in scope; A solid change management process should ensure we do not add things that increase scope; and Strong technical management and good architecture and design reviews, will help ensure we do not deliver a lot of nice to have things that will increase scope.

Before you leave, remember Project scope management requires constant focus on project objectives, sound change management and strong technical management. Treat any request for change, or ideas for improvement, as potential scope creep.

Project Management Checklist

Need a project management checklist for an information management project and want some practical suggestions to ensure rapid project delivery?

A project management plan is a communications tool, which clearly sets expectations for all team members. It helps new team members quickly see who is involved with the project and helps minimize project delays due to miscommunication. It also helps other stakeholders know what is expected of them and when. Some organizations have very large IT departments and staff are assigned to numerous projects at one timeA project plan ensures that all team members know what they are expected to deliver, when it is required, who will accept the deliverable and how it will be approved. The following items should be considered as part of project planning.

Project implementation plan checklist

Are all project management plans complete?

Are project management objectives clearly defined?

Did the project planning phase produce an approved project plan?

Is project resource planning complete?

Have project acceptance criteria been defined and approved by the business owner?

Has the project implementation schedule been reviewed and approved?

Does project team management address:

y y y

Project cost management; Project integration management; and Project management schedule.

Does the project manager have information management project management and leadership skills?

Does the resource plan include:

y y y

Software project management tools; Project management scheduling software; Other critical project resources; and

Software test tools?

Does the project management approach consider rapid project management methodologies?

Are project management processes defined?

Does the project management approach and project methodology address iterative development, prototyping methodology and project management phases?

Does the project management life cycle include lean project management or multi project management techniques?

Does the project management method address project management reports and project time management?

Does the project communications plan address all project management communication?

Is the risk management plan complete?

Does the configuration management plan identify all project deliverables, owners and contributors?

Has software configuration management been addressed?

Does the quality assurance plan include all aspects of project quality management?

Is project management scope defined and clearly defined in the requirements management plan?

Are documentation standards and project management templates defined?

Does the documentation management plan address configuration management requirements for all project documentation and project management documents?

Does project scope management define project change management procedures? Project Management Checklist Summary A project management plan is a communications tool, which clearly sets expectations for all team members. A project management checklist is a good way to ensure complete project planning.