martinvanvuure

Martin’s insteek met monitoring

Wat mij betreft schetst dit plaatje de context van monitoring. Het gaat daarbij om het meten/ detecteren/ waarnemen van gebeurtenissen in systemen. Systemen kunnen fysieke componenten zijn, ketens maar ook logisch of functionele services.. De waarnemingen worden vastgelegd/ gelogd en door het monitoring systeem geinterpreteerd tegen vooraf afgesproken drempelwaarden. Monitoring leidt enerzijds tot rapportage en anderzijds tot (realtime) alerts. Alerts kunnen leiden tot ‘ rode lampjes’ maar ook tot sms’jes of andere meldingen. Meldingen (net als rapportage) zouden tot, vooraf afgesproken, acties of beslissingen moeten leiden. Monitoringsprocesmodel.pdf

Als je kijkt naar het waarom van monitoring (eventregistratie) kom je al snel uit op de doelen en doelstellingen van ITIL-processen als

SLM: The objectives of SLM are to: Define, document, agree, monitor, measure, report and review the level of IT services provided
Availability Management should ensure the agreed level of availability is provided. The measurement and monitoring of IT availability is a key activity to ensure availability levels are being met consistently.
The ability to detect events, make sense of them and determine the appropriate control action is provided by Event Management. Event management is therefore the basis for Operational Monitoring and Control

Met monitoring kunnen we verschillende aspecten van dienstverlening meten:

Beschikbaarheid, QofS, performance, security, capaciteit van resources en services.

Meetbaarheid is hierbij bepalend. Direct meten is het meest recht-toe-rechtaan maar indirect meten geeft uiteraard ook informatie.

Martin’s uitgangspunten en 6 monitoringprincipes

Uitgangspunten bij monitoring

Overschrijding van thresholds leidt tot events ==> events kunnen leiden tot alerts, rapportage of ….
Events meten zonder alerts is zinloos.
Cross functionaliteit, cross Platform, cross silo, cross service, cross applicatie: focus op het geheel.
Zonder meten zul je niets weten.

Wat wel doen:

Onder ken het (poteniele) probleem: beschikbaarheid, performance, gebruik of wat we belangrijk vinden.
Doe dit bij voorkeur zo breed mogelijk dus op service e/o keten niveau en met een insteek zo dicht mogelijk bij de gebruikerservaring. Maak visueel wat je meet. Baken af wat je als ‘systeem’ beschouwd.
Zoek naar “een maat vóór ….het probleem” en maak het meetbaar.
Voer metingen uit en stel een baseline vast, dag/weekprofiel. Maar zorg ook dat je leert: als er een uitval is geweest en hij is niet geregistreerd: onderzoek / neem actie.
Relateer problemen aan tresholds. Maak helder wat de acties zijn bij het overschreiden van tresholds: informatief? correctief? Moet er een ProcessAutomation (PA) script getriggerd worden.
ITTT-IfThisThenThat
Start met bewaken van probleemgebieden / waar je problemen verwacht. Zorg voor e-2-e focus en beperk je tot cruciale metingen.
Schakel overbodige metingen uit. Met een hartslagmonitor loop je geen hardloopwedstrijd: metingen mogen het systeem niet beïnvloeden. Meten moeten nuttig zijn: als je ziek bent, opbouw van vertrouwen .. laten zien dat je in-control bent Als je gezond bent niet meten. Context is alles…..

Wat niet doen:

meten om het meten. Meten zonder vervolgactie is zinloos. Stop metingen zonder vervolgacties (en vervolg acties die niet op meten gebaseerd zijn)
meten van de verkeerde zaken: Met een diefstal-alarm detecteer je geen brand!!
meten als niet-lerend systeem

Om te komen tot monitoring is afstemming over de volgende informatie essentieel: Wat wordt gemeten, wat zijn de drempelwaarden en wat de te nemen acties.

Monitoringbouwstenen

Monitoring systeem

Monitoringsysteem

Toelichting

Loggingsysteem: (Elektronische) verslaglegging systeem om acties vanuit applicaties en infrastructurele componenten vast te leggen.
Logfiles: Bestanden die het resultaat van het loggingsysteem bevatten.
Drempel: Limiet voor het monitoren, die bepaalt of een actie legitiem is.
Waarneming: Een signaal vanuit de infrastructuur die aangeeft of onderdelen in de infrastructuur wel of niet in orde zijn.
Monitoring: Het systeem dat waarnemingen controleert ten opzicht van drempels.
Trigger: Het monitoringsysteem geeft een signaal af, indien een drempel wordt overschreden.
Alerting: Het systeem dat signalen afgeeft als er direct actie ondernomen moet worden, indien er iets mis is met beveiliging of beschikbaarheid van applicaties of netwerkcomponenten.
Reporting: Het systeem dat gegevens bewaart, ten behoeve van management, veiligheid, beheer en marketing. Aan de hand van analyse van de opgeslagen gegevens worden rapporten afgedrukt, waarmee op langere termijn acties genomen kunnen worden.

Met het meetsysteem zijn 2 manieren van monitoring mogelijk:

Active monitoring: probleemoplossend, korte termijn / actueel / .
Pasive monitoring: achteraf / trendsvaststellend / regelmatig / terugkijkend

Realisatie van een monitoringsomgeving is bij uitstek iets wat via een aantal sprints (gedefineerd in een roadmap / plateauplanning (Monitoringplateau) ingericht kan worden. Continual Improvement vormt hierin de basis. Ik verwijs hierbij naar mijn artikel over Capacity management op deze blogsite.

Hoe kijk jij tegen monitoring aan? Wat zijn jouw ervaringen? Heb je suggestie en/of ideeën laat het me weten…(via een reply)

Project Charter Template.pdf

Deze mindmap bevat naar mijn idee alle aspecten van een project. Ik heb onderstaand de bijbehorende tekst weergegeven.

Project Charter Template

1. Statement of Need
INTENDED USE:

The Statement of Need incorporates the client’s business drivers and the current and future state of their environment. Why, is the client looking for a solution? What is the pain or root cause of their need?
INTENDED USE:

The Statement of Need incorporates the client’s business drivers and the current and future state of their environment. Why, is the client looking for a solution? What is the pain or root cause of their need?

2. Benefits
INTENDED USE:
What benefits are expected as a result of implementing the appropriate solution? This section is designed to show why this project is a good business decision. The Benefits must support the MEASURES OF SUCCESS.
EXAMPLE:
The company will see benefits in the following: IBM will be hired to reduce the number of hardware/software platforms being used, increasing stability and ease of maintenance. Individuals in the field can use any modem, increasing speed and functionality, which will enhance their performance when connecting with the [RECOMMENDED SOLUTION]. Reduced number and length of long distance phone calls, due to improved data exchange and on-line availability. Simplify the data exchange process and the system architecture. Meet Year 2000 readiness through the development of new applications that are Year 2000 ready. Reduce maintenance costs. Reduce time spent in supporting the system.

What benefits are expected as a result of implementing the appropriate solution? This section is designed to show why this project is a good business decision. The Benefits must support the MEASURES OF SUCCESS.
INTENDED USE:

What benefits are expected as a result of implementing the appropriate solution? This section is designed to show why this project is a good business decision. The Benefits must support the MEASURES OF SUCCESS.

EXAMPLE

The company will see benefits in the following:

IBM will be hired to reduce the number of hardware/software platforms being used, increasing stability and ease of maintenance.
Individuals in the field can use any modem, increasing speed and functionality, which will enhance their performance when connecting with the [RECOMMENDED SOLUTION].
Reduced number and length of long distance phone calls, due to improved data exchange and on-line availability.
Simplify the data exchange process and the system architecture.
Meet Year 2000 readiness through the development of new applications that are Year 2000 ready.
Reduce maintenance costs.
Reduce time spent in supporting the system.

3. Critical Sucess Factors
INTENDED USE:
In this section key elements that must be in place to ensure the success of the project will be defined. This includes other projects finishing or starting, or certain tasks within other projects being completed. It may include dependencies on the availability of facilities or contractual agreements being finalized.
EXAMPLES: Active executive sponsorship Timely acquisition of required project resources including human, software, and hardware Timely and effective participation of appointed {the client} staff assigned to the deployment team Access to training facilities Acceptance by user community

In this section key elements that must be in place to ensure the success of the project will be defined. This includes other projects finishing or starting, or certain tasks within other projects being completed. It may include dependencies on the availability of facilities or contractual agreements being finalized
INTENDED USE:

In this section key elements that must be in place to ensure the success of the project will be defined. This includes other projects finishing or starting, or certain tasks within other projects being completed. It may include dependencies on the availability of facilities or contractual agreements being finalized.

EXAMPLE

Active executive sponsorship
Timely acquisition of required project resources including human, software, and hardware
Timely and effective participation of appointed {the client} staff assigned to the deployment team
Access to training facilities
Acceptance by user community

4. Measures of Sucess
INTENDED USE:
The Measures of Success (MOS) is a quantified definition of how the project will be measured when it has been completed.
Defining a project’s MOS is one of the most critical and challenging steps in project management. It requires strategic level thinking about the customer, their problems and how the project will help solve those problems. Before we begin to develop an approach and plan for the project, we need to specifically define the desired end result the project will achieve. If we can not quantify and measure this definition, we haven’t stated it properly. Only when we do, can we accurately begin to chart the course to achieve it.
At all costs the project manager must avoid the trap of plunging into the detail before the MOS is agreed upon. He or she must ask the tough questions of the client and the pursuit team up front and define a quantifiable and measurable MOS before the project scope, the approach and budgets are defined.
Finding out how the client will measure success at the end of the project is not an easy task. The measurement is rarely about budget. Often the client is unsure about how to measure the success. Asking detailed questions around “How will you measure [judge, know for sure] the success at the end of the project? What [value, product, improvement, service, knowledge] do you really want to buy for all this money we are asking you to spend?” Working through these question forces the kind of thinking required for successfully planning, executing, and completing projects. With the detailed answers the project manager can drive the project toward the agreed measure of success.
EXAMPLE:
A poor MOS: The objective of the project was to implement a system that will, “Enable the client to provide the best possible customer service.” While the statement sounds good, and certainly no one would disagree with the worthiness of the goal, the statement is vague – the beginning of a project in trouble.
An appropriate MOS: “Reduce the cycle time of customer order entry from two days to one hour.”
The latter statement is measurable and quantifiable. The client may argue about whether this is what they want, and that is the point; we want to define exactly what the “best possible” order entry process (conceptual) is before we start the project.

INTENDED USE:

The Measures of Success (MOS) is a quantified definition of how the project will be measured when it has been completed.
Defining a project’s MOS is one of the most critical and challenging steps in project management. It requires strategic level thinking about the customer, their problems and how the project will help solve those problems. Before we begin to develop an approach and plan for the project, we need to specifically define the desired end result the project will achieve. If we can not quantify and measure this definition, we haven’t stated it properly. Only when we do, can we accurately begin to chart the course to achieve it.
At all costs the project manager must avoid the trap of plunging into the detail before the MOS is agreed upon. He or she must ask the tough questions of the client and the pursuit team up front and define a quantifiable and measurable MOS before the project scope, the approach and budgets are defined.
Finding out how the client will measure success at the end of the project is not an easy task. The measurement is rarely about budget. Often the client is unsure about how to measure the success. Asking detailed questions around “How will you measure [judge, know for sure] the success at the end of the project? What [value, product, improvement, service, knowledge] do you really want to buy for all this money we are asking you to spend?” Working through these question forces the kind of thinking required for successfully planning, executing, and completing projects. With the detailed answers the project manager can drive the project toward the agreed measure of success.

EXAMPLE

A poor MOS: The objective of the project was to implement a system that will, “Enable the client to provide the best possible customer service.” While the statement sounds good, and certainly no one would disagree with the worthiness of the goal, the statement is vague – the beginning of a project in trouble.
An appropriate MOS: “Reduce the cycle time of customer order entry from two days to one hour.”
The latter statement is measurable and quantifiable. The client may argue about whether this is what they want, and that is the point; we want to define exactly what the “best possible” order entry process (conceptual) is before we start the project.

5. Stakeholders & Customers
Identify the individuals within the client organization as well as any external customers and/or trading partners that will experience any level of impact from the scope of this project. Those individuals or groups that are directly impacted by the project are defined as customers. Those individuals or groups that are indirectly impacted are considered stakeholders.

Identify the individuals within the client organization as well as any external customers and/or trading partners that will experience any level of impact from the scope of this project. Those individuals or groups that are directly impacted by the project are defined as customers. Those individuals or groups that are indirectly impacted are considered stakeholders.

6. Scope
The project scope establishes the overall boundaries of the project. This section identifies those elements related specifically to scope. A clear understanding of the scope is key to a successful project.

6.1. Deliverables
INTENDED USE:
The project is organized around deliverables. The purpose of this section is to clearly define the deliverables produced within the scope of this project and establish points of acknowledgement for the customer’s approval signature. The project will be structured around deliverables and identify the tasks needed to complete each deliverable in the planning process. It is important to be specific enough with the language to know when this item begins and ends.
EXAMPLE:
A poorly written deliverable: “Upgrade the network system” is too open-ended.
A well written deliverable: “Upgrade the existing network server to a Pentium 200 processor and 20 Gig hard-drive.” Remember that what may seem obvious to your technical expertise may not be meaningful to your less technical audience.

INTENDED USE:

The project is organized around deliverables. The purpose of this section is to clearly define the deliverables produced within the scope of this project and establish points of acknowledgement for the customer’s approval signature. The project will be structured around deliverables and identify the tasks needed to complete each deliverable in the planning process. It is important to be specific enough with the language to know when this item begins and ends.

EXAMPLE

A poorly written deliverable: “Upgrade the network system” is too open-ended.
A well written deliverable: “Upgrade the existing network server to a Pentium 200 processor and 20 Gig hard-drive.” Remember that what may seem obvious to your technical expertise may not be meaningful to your less technical audience.

6.2. Acceptance Criteria
INTENDED USE:
This section should list definitive and measurable criteria that will answer the question, “How will we know this deliverable is successfully completed?”
This section gives the project manager, the client, and the team the opportunity to see the expected deliverables in black and white. By providing detailed acceptance criteria you are managing the client and teams expectations. Doing this up front reduces the risk of client dissatisfaction, as they and the team know exactly how to measure the success of your deliverables.
Review and acceptance process
Every deliverable will be reviewed by <the client> and acceptance documented. The deliverable signoff form shall be signed by an agreed upon set of stakeholders as they are completed. The entire project, and each phase, shall also be reviewed and signed off by appropriate stakeholders.

INTENDED USE:

This section should list definitive and measurable criteria that will answer the question, “How will we know this deliverable is successfully completed?”
This section gives the project manager, the client, and the team the opportunity to see the expected deliverables in black and white. By providing detailed acceptance criteria you are managing the client and teams expectations. Doing this up front reduces the risk of client dissatisfaction, as they and the team know exactly how to measure the success of your deliverables.

EXAMPLE

6.3. Work Breakdown Structure
INTENDED USE:
The Work Breakdown Structure defines the products to be delivered or produced and decomposes the work necessary to accomplish all of the project’s MOS. The WBS is the foundation for building the project plan. The PLAN describes the activities and sequence necessary to complete the project.
With the MOS defined and approved by the client, we proceed to plan the level of effort required to meet the MOS. We develop the boundaries of the work breakdown structure for the project. We also define the level of involvement in the project required of the client. We define what business units, departments and staff from each need to be involved in the project. We also determine what technical areas of expertise need to be included. At this point, we do not need to worry about the detail necessary to plan the project to the task level. The work effort estimates need to provide sufficient detail about what needs to be done during the project to establish confidence that the deliverables to be produced are reasonable, that the work components are specific enough to be estimated with a high degree of confidence, and that right internal and external controls are implemented. We need to include all functionality that will ensure we will meet the MOS. This level of detail allows the project plan to be prepared in a reasonable amount of time without going into unnecessary complexity. We also need to ensure that no unnecessary activities are included in the project.
EXAMPLE (and there are many ways to graphically portray the deliverables and how they are segmented to provide smaller sets of work within larger sets of work):
<Double click on the chart to edit and format to your specifications>

INTENDED USE:

The Work Breakdown Structure defines the products to be delivered or produced and decomposes the work necessary to accomplish all of the project’s MOS. The WBS is the foundation for building the project plan. The PLAN describes the activities and sequence necessary to complete the project.
With the MOS defined and approved by the client, we proceed to plan the level of effort required to meet the MOS. We develop the boundaries of the work breakdown structure for the project. We also define the level of involvement in the project required of the client. We define what business units, departments and staff from each need to be involved in the project. We also determine what technical areas of expertise need to be included. At this point, we do not need to worry about the detail necessary to plan the project to the task level. The work effort estimates need to provide sufficient detail about what needs to be done during the project to establish confidence that the deliverables to be produced are reasonable, that the work components are specific enough to be estimated with a high degree of confidence, and that right internal and external controls are implemented. We need to include all functionality that will ensure we will meet the MOS. This level of detail allows the project plan to be prepared in a reasonable amount of time without going into unnecessary complexity. We also need to ensure that no unnecessary activities are included in the project.

EXAMPLE

(and there are many ways to graphically portray the deliverables and how they are segmented to provide smaller sets of work within larger sets of work):

6.4. Exclusions
INTENDED USE:
Specifically define any gray areas in both the scope and the deliverables. Setting these expectations up-front will reduce many changes and even disagreements later. Be exact in detailing items not included in the scope of the project. Remember that the audience of the Charter may not have the technical background that would make certain assumptions obvious.
EXAMPLE:
The project scope as it’s defined, defers the installation of the network operating system as a separate effort, not covered under the scope of this project.
The project may include upgrading the network system (you mean the processor and the hard drive), but perhaps excludes the installation of the newest operating system software.
CAUTION! It is important to make certain the client does not perceive the exclusions from scope as effort that we are incapable of or lacking in expertise. Specify the intended use of the section by suggesting that the effort could be defined under a separate charter.

INTENDED USE:

Specifically define any gray areas in both the scope and the deliverables. Setting these expectations up-front will reduce many changes and even disagreements later. Be exact in detailing items not included in the scope of the project. Remember that the audience of the Charter may not have the technical background that would make certain assumptions obvious.

EXAMPLE

The project scope as it’s defined, defers the installation of the network operating system as a separate effort, not covered under the scope of this project.
The project may include upgrading the network system (you mean the processor and the hard drive), but perhaps excludes the installation of the newest operating system software.
CAUTION! It is important to make certain the client does not perceive the exclusions from scope as effort that we are incapable of or lacking in expertise. Specify the intended use of the section by suggesting that the effort could be defined under a separate charter.

The project scope establishes the overall boundaries of the project. This section identifies those elements related specifically to scope. A clear understanding of the scope is key to a successful project.
6.5. Asumptions
INTENDED USE:
Explicit assumptions help to define the conditions under which the project is planned, budgeted, and managed. Whenever possible they should be stated specifically and as early as possible, so they can be used as a reference to identify changes to a project that impact the quality or quantity of deliverables, schedules, costs, etc. Assumptions are an essential part of the charter. They provide an audit trail of how you derived your estimate. This helps the client understand how you came up with your numbers and reminds you of your assumptions if you find that tasks are taking longer or less time to complete. If your assumptions are not valid, then your project is likely to take more or less time, which will impact cost and target date.
There are always unknowns at the start of the project. The project plan gives you a standard to measure against. But the charter is always prepared early in the project when there are unknowns. You will always have variances (favorable and unfavorable) against your estimates as the project proceeds. Assumptions help you understand where and why your estimates may be off, and help you to improve your estimates as you continue on the project or go on to other projects.
Assumptions become a very important element in controlling costs and managing scope. They can also be helpful by clarifying why the project is going to take longer than originally estimated. If an assumption proves to be invalid, the estimate will change. The assumptions enable us to explain the change to the client.
EXAMPLES: System consists of 18 cobol programs. 10 programs are small (< 1,200 loc), 6 are medium (< 2,500 loc), and 2 are large (> 2,500 loc). The client will be responsible for final production and distribution of the technical manual changes. Production costs are not included in the cost estimate. The client will make the subject matter expert available for 2 hours per day during the analysis phase.

INTENDED USE:

Explicit assumptions help to define the conditions under which the project is planned, budgeted, and managed. Whenever possible they should be stated specifically and as early as possible, so they can be used as a reference to identify changes to a project that impact the quality or quantity of deliverables, schedules, costs, etc. Assumptions are an essential part of the charter. They provide an audit trail of how you derived your estimate. This helps the client understand how you came up with your numbers and reminds you of your assumptions if you find that tasks are taking longer or less time to complete. If your assumptions are not valid, then your project is likely to take more or less time, which will impact cost and target date.
There are always unknowns at the start of the project. The project plan gives you a standard to measure against. But the charter is always prepared early in the project when there are unknowns. You will always have variances (favorable and unfavorable) against your estimates as the project proceeds. Assumptions help you understand where and why your estimates may be off, and help you to improve your estimates as you continue on the project or go on to other projects.
Assumptions become a very important element in controlling costs and managing scope. They can also be helpful by clarifying why the project is going to take longer than originally estimated. If an assumption proves to be invalid, the estimate will change. The assumptions enable us to explain the change to the client.

EXAMPLE

System consists of 18 cobol programs. 10 programs are small (< 1,200 loc), 6 are medium (< 2,500 loc), and 2 are large (> 2,500 loc).
The client will be responsible for final production and distribution of the technical manual changes.
Production costs are not included in the cost estimate.
The client will make the subject matter expert available for 2 hours per day during the analysis phase.

6.6. Constraints
INTENDED USE:
Constraints are factors that constrain the project by scope, resource, or schedule.
EXAMPLES: Other systems having the data required available a final due date Limited access to facilities Only a certain number of individuals are available to work on the project

7. Cost Estimates
INTENDED USE:
The cost estimate section of this document should detail the budget requirements for the effort defined within the scope of this project. Costs can be broken down in a number of ways, such as by deliverable, by job function, by project phase, or a combination. Generally, this section can describe the budget in one of 4 ways: No estimate yet, wait until more analysis Estimate the analysis and inventory, estimate the rest later Roughly estimate the whole project for a certain target date Use industry standard estimate figures for similar projects
Estimating guidelines Use the Work Breakdown Structure (WBS) as a basis of your estimate Allow time for meetings and administrative tasks, there are always administrative tasks in a project Can plan for an eight hour day and describe off time piecemeal, or plan for 80% availability for everyone and ignore ‘off-time’ Project management, coordination, meetings, and administrative costs should be included. These can be listed separately or embedded into the costs for specific deliverables. As a rule of thumb, Project management typically represents 20% of the overall budget on project work, but could be more or less depending upon the education and knowledge transfer required of the project lead When estimating costs, be sure to include time for testing and revisions. These amount can vary widely depend on the complexity of the content, the stability of the technology, the expectations of the client, the skill level of the team members, the amount of time devoted to the analysis and design processes, the expertise of the subject matter experts, the review process itself, the number of planned revision cycles, system testing and volume testing requirements, etc Milestones should be designated for specific dates, completion of deliverables, or completion of project phases
Following is a summary of estimated costs based on the milestones detailed in the scope and approach of this project (hours should also be included but are not here, and assignments if known):
Administration $61,150.00 Quality Review $18,750.00 Project Leader $42,200.00 Phase I $188,120.00 Design $24,000.00 Development $124,000.00 Documentation $29,920.00 Testing $10,200.00 Phase II $ 77,040.00 Gather/prioritize Phase II Information $4,000.00 Design $6,400.00 Development $54,000.00 Documentation $10,200.00 Testing $2,040.00 Demo/Training $21,200.00 Beta Test/Rollout $44,000.00 *** TOTAL *** $391,510.00

Estimating guidelines

Use the Work Breakdown Structure (WBS) as a basis of your estimate
Allow time for meetings and administrative tasks, there are always administrative tasks in a project
Can plan for an eight hour day and describe off time piecemeal, or plan for 80% availability for everyone and ignore ‘off-time’
Project management, coordination, meetings, and administrative costs should be included. These can be listed separately or embedded into the costs for specific deliverables. As a rule of thumb, Project management typically represents 20% of the overall budget on project work, but could be more or less depending upon the education and knowledge transfer required of the project lead
When estimating costs, be sure to include time for testing and revisions. These amount can vary widely depend on the complexity of the content, the stability of the technology, the expectations of the client, the skill level of the team members, the amount of time devoted to the analysis and design processes, the expertise of the subject matter experts, the review process itself, the number of planned revision cycles, system testing and volume testing requirements, etc
Milestones should be designated for specific dates, completion of deliverables, or completion of project phases

The cost estimate section of this document should detail the budget requirements for the effort defined within the scope of this project. Costs can be broken down in a number of ways, such as by deliverable, by job function, by project phase, or a combination. Generally, this section can describe the budget in one of 4 ways:

No estimate yet, wait until more analysis
Estimate the analysis and inventory, estimate the rest later
Roughly estimate the whole project for a certain target date
Use industry standard estimate figures for similar projects

8. Approach Strategy
INTENDED USE:
The approach strategy tells your client the path you are planning to take. It justifies the chosen approach over another, if appropriate. It answers the questions, “Why did I decide to do the project this way? How did I come to this conclusion?” It may include qualitative as well as quantitative data, but should be at a high level.
EXAMPLE:
“On the basis of {this survey, interview, market} research and because {of these client, project, content specific} reasons we will {program, design, implement} the {deliverable} in {this particular} way.”

INTENDED USE:

The approach strategy tells your client the path you are planning to take. It justifies the chosen approach over another, if appropriate. It answers the questions, “Why did I decide to do the project this way? How did I come to this conclusion?” It may include qualitative as well as quantitative data, but should be at a high level.

EXAMPLE

“On the basis of {this survey, interview, market} research and because {of these client, project, content specific} reasons we will {program, design, implement} the {deliverable} in {this particular} way.”

The approach strategy tells your client the path you are planning to take. It justifies the chosen approach over another, if appropriate. It answers the questions, “Why did I decide to do the project this way? How did I come to this conclusion?” It may include qualitative as well as quantitative data, but should be at a high level.

9. Organizational Breakdown

9.1. Roles & Responsibilities
INTENDED USE:
This section is used to define the relationships within the project team members including their specific function and level of contribution .
EXAMPLE: Individual(s) Role Responsibilities Executive Sponsor Meets with the Project Manager weekly to review the project plan and approve project plan adjustments Offers tactical business leadership and direction Removes business related barriers Client Provides business rule clarification Authorizes budget Provides business strategic direction Authorizes work and expenditures Provides access Removes obstacles Project Manager Communicates directly to the executive sponsor Works closely with the Project Sponsor and clients Project Member(s), communicating issues and changes that will impact the project Assists in all major project tasks, ensuring tasks are progressing and meeting the project objective Manages project resource utilization Tracks activity progress through the detailed project plan Manages the Issue Tracking Log Performs periodic reviews of the process and generated deliverables Creates a weekly periodic status report Relationship Manager (if appl.) Advises the project manager on issue resolution Partners with the project sponsor May participate on the steering committee Quality Advisor Performs periodic reviews of the process and generated deliverables Interviews selected Stakeholders and the Project Team to gain and understanding of project status and improvement opportunities Advises the project team on approach issues Assists in issue and conflict resolution Generates a summary report after each formal review May provide a project analysis following the project completion if deemed necessary Subject Matter Expert Expertise in a specific area of technology Expertise in a specific area of business Expertise in a specific area of methodology Project Leader Provides estimates to the project manager relative to activities within their area of expertise Directs the work of team members in their group Project Team Member Delivers project tasks Helps with project planning Data collection and reporting Produces deliverables Hands-on work Research and inventory

INTENDED USE:
EXAMPLE

9.2. Governance Plans
INTENDED USE:
The governance plan details the established procedures for issue escalation and resolution. The process should reflect the organization structure as defined by the OBS and the responsibilities as defined in the Stakeholder and Customer section of this document.
EXAMPLE:
Issue Escalation
Issues will surface weekly, if not daily throughout the course of the project. Effective issue tracking and resolution are critical to the success of the project. The following issue escalation process is recommended.
Tier 1 – Project Team to Project Manager
Project Team members escalate issues to the Project Manager who in turn documents the issue(s) on the Issue Tracking Log (see the Project Controls section of this document). The log is reviewed throughout the week by the Project Manager to ensure issues are being appropriately addressed and closed.
Tier 2 – Project Manager to Quality Advisor
The Project Manager escalates issues to the Quality Advisor to ensure the appropriate management members are fully aware of unresolved critical issues. The Quality Advisor will assist the Project Manager in resolving the issue, if possible. If resolved, the Project Manager will update the Issue Tracking Log and close the issue.
Tier 3 – Project Manager to Project Sponsor
The Project Manager escalates issues to the Project Sponsor to ensure the {Client} management members are fully aware of unresolved critical issues. The Project Sponsor will assist the Project Manager in resolving the issue, if possible. If resolved, the Project Manager will update the Issue Tracking Log and close the issue. In addition, the Project Manager will inform the Quality Advisor of the issue status and resolution if applicable.
Tier 4 – Project Manager to Relationship Manager(Account Manager)
The Project Manager escalates issues to the Relationship Manager if the issue requires exectuve representation.
Tier 5 – Relationship Manager to Project Sponsor
The Relationship Manager to attempt to gain closure on an issue prior to escalation to the Steering Committee. The Project Sponsor will assist the Relationship Manager in resolving the issue, if possible. If resolved, the Project Manager will update the Issue Tracking Log and close the issue.
Tier 5 – Project Manager/Relationship Manager Steering Committee
The Project Manager and/or the Relationship Manager escalates the most sensitive and urgent issues to the Steering Committee to ensure the appropriate {Client} senior management members are fully aware of unresolved critical issues. The Steering Committee will assist the Project Manager in resolving the issue, if possible. When resolved, the Project Manager will update the Issue Tracking Log and close the issue.

INTENDED USE:

The governance plan details the established procedures for issue escalation and resolution. The process should reflect the organization structure as defined by the OBS and the responsibilities as defined in the Stakeholder and Customer section of this document.

EXAMPLE

Issue Escalation

Issues will surface weekly, if not daily throughout the course of the project. Effective issue tracking and resolution are critical to the success of the project. The following issue escalation process is recommended.

Tier 1 – Project Team to Project Manager

Project Team members escalate issues to the Project Manager who in turn documents the issue(s) on the Issue Tracking Log (see the Project Controls section of this document). The log is reviewed throughout the week by the Project Manager to ensure issues are being appropriately addressed and closed.

Tier 2 – Project Manager to Quality Advisor

The Project Manager escalates issues to the Quality Advisor to ensure the appropriate management members are fully aware of unresolved critical issues. The Quality Advisor will assist the Project Manager in resolving the issue, if possible. If resolved, the Project Manager will update the Issue Tracking Log and close the issue.

Tier 3 – Project Manager to Project Sponsor

The Project Manager escalates issues to the Project Sponsor to ensure the {Client} management members are fully aware of unresolved critical issues. The Project Sponsor will assist the Project Manager in resolving the issue, if possible. If resolved, the Project Manager will update the Issue Tracking Log and close the issue. In addition, the Project Manager will inform the Quality Advisor of the issue status and resolution if applicable.

Tier 4 – Project Manager to Relationship Manager(Account Manager)

The Project Manager escalates issues to the Relationship Manager if the issue requires exectuve representation.

Tier 5 – Relationship Manager to Project Sponsor

The Relationship Manager to attempt to gain closure on an issue prior to escalation to the Steering Committee. The Project Sponsor will assist the Relationship Manager in resolving the issue, if possible. If resolved, the Project Manager will update the Issue Tracking Log and close the issue.

Tier 5 – Project Manager/Relationship Manager Steering Committee

The Project Manager and/or the Relationship Manager escalates the most sensitive and urgent issues to the Steering Committee to ensure the appropriate {Client} senior management members are fully aware of unresolved critical issues. The Steering Committee will assist the Project Manager in resolving the issue, if possible. When resolved, the Project Manager will update the Issue Tracking Log and close the issue.

10. Work Plan
INTENDED USE:
EXAMPLE
INTENDED USE:
This section of the document depicts a high-level work plan providing phases, milestones and major deliverables. Any application tools used for the management of the project are also specified.
At this level the project plan details timeline information for milestones and deliverables. This can be represented in an outline format or an object originated in a scheduling application.
Project Plan Guidelines: Refrain from using calendar dates Use ordinal dates to show timeline

This section of the document depicts a high-level work plan providing phases, milestones and major deliverables. Any application tools used for the management of the project are also specified.
INTENDED USE:
EXAMPLE

11. Project Control Strategies

11.1. Quality Assurance
INTENDED USE:
This section describes the internal controls established by the Quality Assurance process.
EXAMPLE:
Tests required include unit testing, format testing (forms, screen design, prototypes, etc.) system testing unit testing, stress testing, environment testing, market testing. Forms and procedures may be documented here.

INTENDED USE:

This section describes the internal controls established by the Quality Assurance process.

EXAMPLE

Tests required include unit testing, format testing (forms, screen design, prototypes, etc.) system testing unit testing, stress testing, environment testing, market testing. Forms and procedures may be documented here.

11.2. Change Control
INTENDED USE:
Any change in scope could have an impact on the project charter, plan, schedule, or overall cost of the project. Policy issues regarding managing changes in scope will be detailed in this section.
EXAMPLE:
The Project Manager will notify the Executive Sponsor with a Project Change Request and seek the Client’s approval before proceeding to implement the changes. Change requests must be executed by the Project Manager. The Project Manager keeps a log of all changes. Each change requested must be resolved within 7 days and the reason for acceptance, denial, or postponement documented.

INTENDED USE:

Any change in scope could have an impact on the project charter, plan, schedule, or overall cost of the project. Policy issues regarding managing changes in scope will be detailed in this section.

EXAMPLE

The Project Manager will notify the Executive Sponsor with a Project Change Request and seek the Client’s approval before proceeding to implement the changes.

Change requests must be executed by the Project Manager.
The Project Manager keeps a log of all changes.
Each change requested must be resolved within 7 days and the reason for acceptance, denial, or postponement documented.

11.3. Issues
INTENDED USE:
Issues are any events or situations that may arise during a project that may impede progress. This section is intended to identify how issues will be identified, addressed and resolved.
EXAMPLE:
Issues will be addressed at the lowest possible level. The Project Manager will keep an Issue Log and keep the Executive Sponsor apprised of all issues and their current state on a regular basis. Once identified, issues are to be logged by the Project Manager. The Project Manager will resolve the issue or escalate as appropriate. Issues will be reviewed as part of the standard Project Status reporting to ensure their resolution effort continues.

INTENDED USE:

Issues are any events or situations that may arise during a project that may impede progress. This section is intended to identify how issues will be identified, addressed and resol

EXAMPLE

Issues will be addressed at the lowest possible level. The Project Manager will keep an Issue Log and keep the Executive Sponsor apprised of all issues and their current state on a regular basis.
Once identified, issues are to be logged by the Project Manager.
The Project Manager will resolve the issue or escalate as appropriate.
Issues will be reviewed as part of the standard Project Status reporting to ensure their resolution effort continues.

11.4. Communications
INTENDED USE:
A communication strategy must be established and documented in this section of the project charter. The strategy should reflect the vehicles used for inter-project communications between teams and the members of a project team. A project of substantial scope may require a separate communications plan.
EXAMPLE:
Status Reports
Status Reports will be submitted to <the Client> on a <weekly> basis. These reports provide a snapshot of completed and upcoming tasks, issues and concerns and budgets.
Conference Calls
Conference calls will be held with <the Client> on a <weekly> basis. During these calls, the Executive Sponsor will have the opportunity to address any concerns or changes in the project and review the Status Report with the Project Manager.
Meetings
Meetings with <the Client> will be scheduled around the following milestones: <bullet list milestones. >

INTENDED USE:

A communication strategy must be established and documented in this section of the project charter. The strategy should reflect the vehicles used for inter-project communications between teams and the members of a project team. A project of substantial scope may require a separate communications plan.

EXAMPLE

Status Reports

Status Reports will be submitted to <the Client> on a <weekly> basis. These reports provide a snapshot of completed and upcoming tasks, issues and concerns and budgets.

Conference Calls

Conference calls will be held with <the Client> on a <weekly> basis. During these calls, the Executive Sponsor will have the opportunity to address any concerns or changes in the project and review the Status Report with the Project Manager.

Meetings

Meetings with <the Client> will be scheduled around the following milestones: <bullet list milestones. >

11.5. Information Management
INTENDED USE:
This refers to the way information about the project will be documented, tracked, archived, revised, and accessed for internal project management purposes. It does not refer to documentation of the subject matter as a project deliverable. This information should be contained in the Project Workbook/Repository, maintained onsite by the Project Manager. This may, physically, be a binder, file set, and/or an electronic repository. Certain signed materials, including contracts, material acceptance forms and project change notices should be duplicated, storing the original materials at a secure facility.
Project Workbook Repository
In an effort to manage and maintain project documentation, the Project Manager will maintain a binder, file set and/or electronic repository of every completed report and form.
Client Information
Establish the process in which the project team will acquire, distribute and manage client information.
Vendor Information
Define the requirements and process necessary for gaining access to and managing information proprietary to any vendors that are involved in contributing the success of the project.
The Project Workbook/Repository should include the following: Proposal and Project Charter Original, signed proposal, charter and contract Applicable Addendum(s) Project Plan Detailed Design Vendor documentation Industry reports Estimates Work Breakdown Structures/Schedules Original and Latest versions Issue Log/Resolutions Risk Assessments and Log Project Change Requests and Log Meeting Notes Charts and Graphics Current System reports and documentation Executive Status Reports Personal Status reports Project Status reports and Weekly Task Reports Project Financial Reports Project Correspondence Incoming and Outgoing Internal memos Final report and assessment Deliverable Acceptance Signoffs Final Deliverables Paper version (if appropriate) On-line version Purchase Orders/Invoices Financial Reports

INTENDED USE:
EXAMPLE

12. Risk Management
INTENDED USE:
During the execution of the project, risks that have a potential negative impact on the outcome of the project may be uncovered. The project leader will use the Risk Management Log to implement formal procedures for managing issues on the project.
A risk/opportunity questionnaire analysis will be scheduled to periodically review risk potential and subsequent risk management.
EXAMPLE:
Risk areas include changes to system, doc, lack of education/skills, etc. Identify risk areas and define who is responsible for monitoring as well as a mitigation process.

INTENDED USE:

During the execution of the project, risks that have a potential negative impact on the outcome of the project may be uncovered. The project leader will use the Risk Management Log to implement formal procedures for managing issues on the project.
A risk/opportunity questionnaire analysis will be scheduled to periodically review risk potential and subsequent risk management.

EXAMPLE

Risk areas include changes to system, doc, lack of education/skills, etc. Identify risk areas and define who is responsible for monitoring as well as a mitigation process.

13. Logistics
INTENDED USE:
Describe in the Logistics section all the requirements for space, equipment, travel, etc..
EXAMPLE:
The project requires the following facilities and resources: A desk, cubical, or office space and furniture for 3 new individuals with a PC for each (PC requriements) A telephone that includes internal and external lines An additional, analog, remote access service telecommunications line A Token Ring or Ethernet network connection Computer network access and password Building access authorization for the facilities that team members will need to enter

INTENDED USE:

Describe in the Logistics section all the requirements for space, equipment, travel, etc.

EXAMPLE

The project requires the following facilities and resources:

A desk, cubical, or office space and furniture for 3 new individuals with a PC for each (PC requriements)
A telephone that includes internal and external lines
An additional, analog, remote access service telecommunications line
A Token Ring or Ethernet network connection
Computer network access and password
Building access authorization for the facilities that team members will need to enter

14. Approval Signatures
15. Glossary/Acronym
16. Additional Related Documents
Legenda

Project Charter Template.mmap

Allerlei aspecten van een project die je in éeén A4′tje zou moeten willen hebben….
1/1/2009
Reference

Martin van Vuure

martin.vanvuure@kpn.com

Toe toevoegen zaken

Ontwerpen: (84%)	Ontwikkelen:
Traditionele organisaties	Flexibele/innovatieve organisaties
bron v. tekortkomingen	verbeteren vanuit bestaande situatie
blauwdruk (plan en implement)	groen / leren (testing and learning)
top-down	gebruik kennis/inzicht personeel (bottom-up)
oplossingsgericht	Probleemgericht (concreter, in heden)
stabiele eindsituatie	vergroting verandervermogen
Eenmalig / linear	Voortdurend iteratief
strakke normen / planning	aandacht voor veranderingscapaciteit
econ. – technische realiteit	sociaal-politieke rationaliteit
Van abstract naar concreet (deductief)	van concreet naar abstract (inductief)
Scheiding ontwerp en invoering	vloeiende overgang tussen fasen
Beperkte tijd/haast	groei / continual improvement
Drastische veranderingen / afbouw	geleidelijkheid
waterval	agile / scrum (ResultatOptimierungsModell)

Begrijpen en organiseren van data

Ben je MrX of MrNiks

8 kenmerken van een volwassen service portfolio

Samenvatting IT in de zorg (boek (2))

Samenvatting IT in de zorg (boek (1))

The power of checklists🔥👍

Stappen naar control

5 stappen naar een Actionplan

6 te nemen Planningsstappen

12 Projectvalkuilen

IT organisatie van de toekomst

Martin’s insteek met monitoring – 6 monitoringprincipes

Hoe kijk jij tegen monitoring aan? Wat zijn jouw ervaringen? Heb je suggestie en/of ideeën laat het me weten…(via een reply)

Optimaal

Readers

Pendelen tussen ontwikkelen en ontwerpen

Project Charter Template

Mijn favoriete iPad apps voor zakelijk gebruik

7 Tips voor het organiseren van masterdata

Action mapping

Ideation