White Paper - Data Warehouse Project Management

WHITE PAPER

Data Warehouse

Project Management

DAVID M WALKER

Version: 1.0

Date: 14/10/2008

Data Management & Warehousing

138 Finchampstead Road, Wokingham, Berkshire, RG41 2NU, United Kingdom

http://www.datamgmt.com

Data Management & Warehousing

White Paper - Data Warehouse Project Management

© 2008 Data Management & Warehousing

Page 2

Table of Contents Table of Contents ...................................................................................................................... 2!Synopsis .................................................................................................................................... 3!Intended Audience .................................................................................................................... 3!About Data Management & Warehousing................................................................................. 3!Introduction................................................................................................................................ 4!Common Problems.................................................................................................................... 5!

Setting the wrong expectations ............................................................................................. 5!Managing the Technical Architecture.................................................................................... 7!Resource Turnover ............................................................................................................... 8!

The building blocks of a project control ..................................................................................... 9!Phases .................................................................................................................................. 9!Milestones ........................................................................................................................... 10!Activities .............................................................................................................................. 10!Tasks................................................................................................................................... 10!Issues.................................................................................................................................. 11!Enhancements .................................................................................................................... 11!Test cases........................................................................................................................... 12!Defects ................................................................................................................................ 12!Risks ................................................................................................................................... 12!

The Event Horizon................................................................................................................... 14!Short Term .......................................................................................................................... 14!Medium Term ...................................................................................................................... 14!Long Term........................................................................................................................... 14!

Tools and Technology ............................................................................................................. 15!Project Management Software............................................................................................ 15!Ticketing.............................................................................................................................. 15!Version Control ................................................................................................................... 16!Wiki ..................................................................................................................................... 17!

Methodologies ......................................................................................................................... 18!Project Leadership .................................................................................................................. 19!

The Executive Sponsor ....................................................................................................... 19!Project Sponsor................................................................................................................... 19!Project Manager.................................................................................................................. 20!Technical Architect.............................................................................................................. 20!Senior Business Analyst ..................................................................................................... 21!Leadership Style ................................................................................................................. 21!Organisational Learning ...................................................................................................... 22!Team Rotation..................................................................................................................... 23!

Estimating and Effort ............................................................................................................... 24!Tips and Tricks ........................................................................................................................ 26!Summary ................................................................................................................................. 28!Appendix 1 – Governance Procedures ................................................................................... 29!

Change Management Processes........................................................................................ 29!Data Warehouse Processes ............................................................................................... 30!Data Management Processes............................................................................................. 31!

Appendix 2 – Project Services ................................................................................................ 32!Copyright ................................................................................................................................. 32!



Page 3

Synopsis Data warehouse projects pose a specific set of challenges for the project manager. Whilst most IT projects are a development to support a well defined pattern of work a data warehouse is, by design, there to support users asking ad hoc questions of the data available to the business. It is also a project that will have more interfaces and more change than any other system within the organisation. Projects often have poorly set expectations in terms of timescales; the likely return on investment, the vendors’ promises for tools or the expectations set between the business and IT within an organisation. They also have large technical architectures and resourcing issues that need to be handled. This document will outline the building blocks of good project control including the definition of phases, milestones, activities, tasks, issues, enhancements, test cases, defects and risks and will discuss how they can be managed, and when, using an event horizon, the project manager can expect to get information. To help manage these building blocks this paper will look at the types of tools and technology that are available and how they can be used to assist the project manager. It also looks at how these tools fit into methodologies. The final section of the paper has looked at how effective project leadership and estimating can improve the chances of success for a project. This includes understanding the roles of the executive sponsor, project manager, technical architect and senior business analyst along with the use of different leadership styles, organisational learning and team rotation.

Intended Audience

Reader Recommended Reading Executive Entire Document Business Users Synopsis IT Management Entire Document IT Strategy Synopsis IT Project Management Entire Document IT Developers Synopsis

About Data Management & Warehousing Data Management & Warehousing is a specialist consultancy in data warehousing, based in Wokingham, Berkshire in the United Kingdom. Founded in 1995 by David M Walker, our consultants have worked for major corporations around the world including the US, Europe, Africa and the Middle East. Our clients are invariably large organisations with a pressing need for business intelligence. We have worked in many industry sectors but have specialists in Telco’s, manufacturing, retail, financial and transport as well as technical expertise in many of the leading technologies. For further information visit our website at: http://www.datamgmt.com



Page 4

Introduction

Data warehousing projects are notorious for both being delivered late and over budget. Why is this and what can be done to prevent it? The common problems that affect the data warehouse can be grouped by the expectations that are set, the technology used and the management of resources. There is also a need to define the components of project control and to develop understanding of the level to which these can be planned and forecast. With this understanding it is possible to look at tools, technologies and methodologies that can assist the project manager to control, support and deliver a solution. Finally this paper looks at the impact of project leadership techniques and the effect that good estimate efforts can have on the delivery of a project. This paper does not set out to be an exhaustive manual for the management of a data warehouse project, rather a guide to help project managers understand the difference between data warehousing projects and others that they may have been responsible. It also suggests some things that should be considered when managing such projects.



Page 5

Common Problems Data warehouse projects often suffer from poorly set expectations, problems with the technical architecture and resource turnover. These common categories have multiple and varied underlying causes:

Setting the wrong expectations The failure to set the right expectations of a data warehouse is part of every project and the reason that they are often perceived not to deliver. This failure to set expectations occurs at many levels:

• Timescales For most large organisations a data warehouse project will have many phases, take years to build and have to be supported for many more years afterwards. Development and production phases will overlap and once in production the environment will be subject to massive amounts of change. When a Data Warehouse project is conceived it will not be discussed in these terms but as just another project with a finite timescale and a simple set of phases.

• Return on Investment The business case generated to justify a data warehouse project will always make a number of promises about return on investment, which are deemed necessary to get the budget. However, the real benefit will either come from an unexpected quarter (e.g. a fraud being discovered or the ability to drop a costly product range) or be from intangible benefits (e.g. business analysts that stop creating their own small database and spreadsheet applications and start analysing the business and delivering indirect business benefit). Business cases should be looked upon as a reason for starting rather than a defined return on investment. The deliverable, and therefore the return on investment should be measured in terms of what benefit was derived rather than against some planned benefit. Some phases will deliver more, and some less than expected.

• Vendor set expectations of tools Data Warehousing and Business Intelligence tool are purchased with an expectation of productivity gains and reduced total cost of ownership however the reality is often more complex:

o One reporting tool will not be sufficient for all your reporting needs.

o An ETL tool provides a well-defined development environment but often does not provide the productivity benefits promised and requires more expensive, specialist resources.

o It is often difficult to integrate the tools in the advertised way.

o Changing from one tool to another often does not fix the underlying issue, or does so only at significant cost.

o Technology sets leapfrog one another; a unique feature in one tool will often be in another with the next release.



Page 6

• IT set expectations to the business IT are often guilty of being over-optimistic about the point at which the benefit will occur:

o The initial phases of a project are about understanding and infrastructure. It is only when these are in place that the business facing solution can be deployed.

o Quick-win solutions, whilst valuable in the short-term, have a long-term cost that has to be accounted for. This is because there is both an on-going management cost and a de-commissioning cost that the business will have to pay later. Quick-win solutions often also compromise data quality that in turn damages user confidence in the system

o The final solution can never be reconciled exactly against the current solution, this is because there will be unknown bugs in the currently delivered solution, new sources of data and different treatments of that data. It should, however, be possible to explain all the differences.

o The testing and issue resolution of a system will take longer than expected.

• Business set expectations to IT The business will often point to IT for its failings but it too will fail to manage expectations. Commonly:

o The business will not invest the time required to deliver requirements and analysis.

o The data quality will be much worse than the business is prepared to acknowledge and the business will be slow to respond to the need to change working practices to improve the data quality.

o The business will not spend enough time or dedicate enough resource to testing.

o The business will not spend enough time or dedicate enough resource to training.

o There will be phases of the project where they lose focus as other business critical events take place.

o When the time comes to de-commission existing solutions and tactical solutions built along the way the business will be unwilling or unable to do so, often fearing that some piece of data has been overlooked.



Page 7

Managing the Technical Architecture

The technical architecture of a data warehouse is the framework on which the solution is delivered. Data Warehouses are often described as ‘complex’ without further explanation. It is not that the process itself is difficult (copy data from the source systems, format it and write a report on it), nor does it need unusually complex technology to deliver. Instead the complexity comes from the scale of the solution. A reasonable sized data warehouse will have thousands of individual ETL mappings and hundreds of reports all serving a large community of users quickly. In order to do this it is important to observe the following principle:

Keep the architecture simple Whilst this may seem obvious, simplicity is hard to do and has to be regularly worked on. Keeping things simple requires a conscientious decision. Some common examples include:

o Small is beautiful. Creating more simple ETL mappings rather than large single blocks of code makes change and maintenance easier. Have a larger number of smaller data marts rather than one single ‘super-mart’ which results in complex change management. Have multiple reports for different people instead of one that tries to satisfy everyone. A change to meet a requirement from one user will undoubtedly leave another user unhappy.

o Have discreet ‘componentised’ functionality. Use the right tool for the job. For example don’t store data in the ETL tool, don’t use a reporting tool to perform ETL, extract data for downstream sources in a consistent way, etc.

o Ensure that the data load process is complete and auditable. It is common for data warehouses to allow direct updates to the database by DBAs etc to maintain reference data. This should be prohibited and an application provided to the business for them to perform this functionality.

1

o Minimise components.

There is often a temptation to make tweaks to the technical architecture to have a larger number of ‘best of breed’ tools to accommodate certain requirements. In practice this increases the maintenance costs and support skills required whereas the existing toolset can often provide a sufficient solution.

o Keep it clean. A data warehouse whose data is not clean quickly falls into disrepute and becomes unused. The technical architecture has to support data quality monitoring and data cleansing and there must also be processes to deliver change in the source system.

1 This may seem counter-intuitive, how can writing a whole separate application to maintain data be simpler than just

writing the SQL? The reason for this requirement is that there is no audit trail and therefore no way of knowing what updates have been done. If instead a business user has to maintain the data via an application and this is loaded into

the data warehouse via ETL then the business takes responsibility for maintaining the data and there is an audit trail of where the data change came from. Writing SQL also creates a large number of small, ad-hoc SQL jobs. This takes time and sooner or later someone will make a mistake with the SQL that may take a lot of work to correct.



Page 8

o Tactical Solutions. Every project has them and there is often a very good case for them but they always cost more to remove than to create and often de-rail the ‘keep it simple’ principle. If tactical solutions become necessary then they should have an implementation, an expected lifetime, maintenance cost for the lifetime, a lifetime-overrun cost and a decommissioning cost. When presented with these costs tactical solutions often look a lot less appealing.

o Have an active de-commissioning policy. Data Warehouses have a lot of code that needs to be maintained and takes time to run. If database entities are no longer used then de-commission them and the ETL that feeds them. The same is true for a report that has been replaced or just fallen into disuse.

Resource Turnover

Data Warehouses are long-term projects and are likely to engage internal and external staff for several years. For a variety of reasons staff will come and go during that time. It is also possible for the new arrivals to bring new ideas and ways to improve what is being done. Whilst this is to be welcomed it also presents a very specific and potentially expensive risk. This often manifests itself when new members of staff come in and say ‘I wouldn’t have done it this way – let’s start doing it another way’ For whatever reason a significant change in direction most often results in one of two outcomes; expensive re-work to keep a consistent architecture or a complex architecture that requires more support and documenting the route to the current point can avoid such re-work.

2

In addition ensure that there is sufficient briefing material available so that new starters can get up to speed quickly and before launching into the ‘I wouldn’t have done it this way’ discussions.

2 Key Design Decisions – a template for documenting critical decisions in the design process. See the ‘Data

Warehouse Documentation Roadmap’ white paper from Data Management & Warehousing



Page 9

The building blocks of a project control The following section offers a description of the components of the project control (the project plan in conjunction with project risks, issues and defects). Whilst all the terms will be familiar to readers they are described here to ensure consistent use and discuss the interaction between them.

Phases

The phase of the program is a set of work with a defined outcome that delivers benefit to the project as a whole. Note that there should be phases of the project that do not deliver direct business benefit but are required for the project to succeed. It would be common for a data warehouse project to have the following initial phases:

• Phase 1: Mobilisation (2 weeks).

This short phase at the start of a project aims to get everything ready for the team to begin. It includes getting building passes, office space, network access, systems permissions and other basic structures in place. Too often there is a perceived need to see everyone on site

3 and working on day one. In

reality this normally wastes a significant amount of resource that will be required in the later phases of the project.

• Phase 2: Technical Architecture & Initial Business Requirements (4-8 weeks). This second phase is about putting a sound basic infrastructure in place. The technical architecture provides a solid platform on which to build whilst the initial business requirements are used to develop a list of priorities for development. These also provide the basis for developing the initial resourcing plans for enlarging the team.

• Phase 3: Data Warehouse Infrastructure Deployment (4-8 weeks). With this phase sufficient hardware and software is deployed and the initial data warehouse logical data model created and a plan for the subsequent phases of data mart deployment is developed.

• Subsequent Phases: Data Mart Delivery (3-6 months each). From this point on the iterative development of data marts and reporting solutions can begin. Each phase represents a deliverable of direct business benefit.

Phases can overlap but only in a controlled way such as not to cause resourcing or technical conflict between phases. The above outline means that whilst the speed of delivery gets faster later in the project the initial delivery will be six to nine months from inception. Phases are often driven by an enhancement packaging process

4 that groups together a

series of requirements and enhancements into a phase scope definition.

3 This is particularly common in system integrator run projects where the client often says “How big is your team and

when will they arrive?” because the client want to see movement on the project. 4 See Appendix 1 for a description of governance processes for a data warehouse environment



Page 10

Milestones

Milestones are the checkpoints within a phase of the project. For example each data mart phase may have milestones that indicate the completion of Requirements Gathering, Analysis, Design, Build, Test, Deployment, Training, etc.

Activities

Activities describe what needs to be done to complete a specific milestone. Therefore the milestone ‘Analysis Complete’ may have activities such as ‘Identify Potential Source Systems’, ‘Perform Data Quality Analysis’, ‘Perform Source System Analysis’, etc. These are normally carried out by a team or group of people and normally have estimated elapsed durations associated with them. Whilst some activities are dependent on others many will have dependencies at a lower level. For example whilst the activity ‘Indentify Potential Source Systems’ is going on there may be no reason why the ‘Perform Data Quality Analysis’ for the first identified system cannot start.

It is often difficult to represent this in a project management tool and common for project managers to reflect the situation as a number of activities of fixed duration that are dependent on the completion of one before the next starts, or not to have any dependencies between activities. Both methods cause the plan to slip.

Tasks

Tasks are the specific items of work to be carried out by an individual. It is important that a named individual is responsible for the task, not a group or a team. Where a task is not yet assigned to an individual it should be assigned to the team leader so that they are aware that they have to (re-)assign it on to someone to actually do the work. It should also be noted that tasks can have sub-tasks, for example the task ‘Document Technical Architecture’ may require sub-tasks of ‘Document Database Architecture’ and ‘Document Hardware Architecture’. All three of these tasks should also have an individual owner who may or may not be the same person as the person responsible for bringing the whole document together. Tasks also have real dependencies on other tasks being completed. Individuals can work very effectively if they have a bank of outstanding tasks, each with a priority and if they cannot work on one task can move to the next one quickly and easily. Issues may hold up tasks.



Page 11

Issues

An issue is something that affects the progress of the project. Issues can occur at a project level or affecting an individual task. For example:

• A team member going off unexpectedly on long-term sick leave is a project level issue that needs to be resolved.

• The inability to get a username and password for an individual system that prevents someone completing a source systems analysis is a task level issue.

Issues introduce delays in the project and so it is important to see the impact of issues as soon as possible.

• Project level issues should be driven down to task level as quickly as possible. Using the example above of long term sickness the process of driving it down to task level would be to re-assign tasks that belonged to that individual to others.

• Task level issues often mean that the person responsible moves onto the next task in the task bank and can come back to the other task when the issue is resolved.

Mistakes and consequently issues are inevitable on a project. As such active management and an environment where mistakes are accepted, learnt from and documented is to be favoured over one in which people try to hide their mistakes. An understanding of the types of issues over the lifecycle of the project is the first step towards improving both the quality and speed of delivery. An Issue Management Process should manage issues

5

Enhancements

An enhancement is a change to the system with the aim of improving it. In a development such as a data warehouse where new requirements are continuously being developed it usual that an enhancement is captured, considered and if appropriate worked into the requirements documentation for inclusion in a subsequent phase via the enhancement packaging process. Not all enhancements need to go through the requirements process. Some, such as an improved navigation paradigm for the user interface, may be considered and passed directly as a task to the person who can affect the change. This rapid response process is very useful if there are separate teams responsible for issues and maintenance as well as the main development teams.

5 See Appendix 1 for a description of governance processes for a data warehouse environment



Page 12

Test cases

Test cases are a special type of task associated with testing. A test case is a set of tasks supported by scripts and routines that help automate and manage the testing of software. Every piece of code developed should have an associated test case. Where an issue is found with the code it becomes a defect that has to be rectified. A test case may reveal many defects, or none and test cases may have to be repeated a number of times until the code is defect free. In some environments it is useful to consider not only code but also the review of documents as test cases and the issues raised from the review as defects. This allows a separation in the reporting between tasks originally associated with the plan and work carried out because of the incompleteness of the deliverable (i.e. defects). The test case for a document would simply be to review it. As with issues above, mistakes are inevitable in the development process and therefore should be accepted and documented as part of improving the process rather than being hidden away.

Defects Defects are a special type of issue associated with testing. A defect is a material error with a deliverable. In the case of code this may be as a result of an undelivered but promised requirement, a misinterpretation of the requirements, unexpected results (common when testing boundary conditions and exceptional usage) etc. A defect should be resolved before the code is deployed (even if the resolution is to say that the functionality will be delivered in a subsequent phase). This can also be applied to review comments for documentation that are, in effect, defects in the deliverable. Each defect should be reviewed and changes applied where appropriate before the defect is closed.

Risks

There may be external circumstances or events that cannot occur for the project to be successful. If you believe such an event is likely to happen, then it would be a risk. Identifying something as a risk increases its visibility, and allows a proactive risk management plan to be put into place.

6

If an event is within control of the project team, such as having testing complete by a certain date, then it is not a risk. If an event has a one hundred percent chance of occurring, then it is not a risk, since there is no "likelihood" or risk involved but it is an issue.

Examples of risks might be a "Re-organization may result in key people being reassigned," or "The new hardware may not be able handle the expected volume."

Risks are managed by developing mitigations or ways in which to avoid the risk or prevent it from becoming a reality.

6 http://www.mariosalexandrou.com/definition/risk.asp



Page 13

A risk can be quantified in two dimensions:

• The first is the probability of it happening which is a measure of how likely it is that a risk will become an issue.

• The second is the impact that is a measure of the impact in terms of resource,

time or scope.

Projects usually measure both of these dimensions on a High/Med/Low type scale. This can produce a grid as illustrated.

The grid can then be used to assess the level of mitigation (or actions to prevent the risk from becoming an issue) that should be associated with each of the risks.

Obviously the ‘hotter’ the risk the more attention that should be paid to developing mitigation for that risk.

This can all be summarised in the diagram below:

Figure 1 - Project Control



Page 14

The Event Horizon

Projects are often expected to have detailed plans from start to finish; in practice this is both unrealistic and impossible to maintain for data warehouse projects. Instead projects should aim to deal with the plan depending on when events are likely to happen.

Short Term

Current or near term phases need to be tracking every aspect of the work from the scope (enhancements) through milestones, activities, risks, tasks, test cases and for the current and next phase issues and defects. It is the issues and defects that will cause the current phase to be delayed or have other resource impact. The financial implications in the short term are over-spending or use of contingency because there is no space in which to manoeuvre.

Medium Term Phases further out need to have the scope, milestones, activities, risks and where possible tasks planned out. These plans, their timescales and the budget for these phases should be adjusted in the light of experience gained on current and previous phases should influence the work being defined for these phases.

Long Term

Long-term plans are normally limited to rough scopes of work and timescales (for example we hope to add market segmentation to the data warehouse and expect it to take 5 people 3 months). This allows estimated budget requirements to be calculated but is highly dependent on the timescales and successful delivery of the previous phases. Learning from current work will improve the estimating over time.

Using the above definitions it is possible to indicate what information a project manager should ideally have available in the following graphical way:

Figure 2 - Information available to a project manager In practice managers normally have even less information available (indicated by the red line). This means that both the short-term and medium-term horizons each cover two phases rather than the three phases of the ideal situation. The long-term view is then restricted to knowing what enhancements are needed.



Page 15

Tools and Technology In order to manage such a large-scale project it is important to use a number of tools to help keep track of all the aspects of the project. There are six major groups of software

7 that are needed for corporate programme/project

management:

• Project Management Software8

• Collaborative Software9

• Ticket Tracking Systems10

• Project Portfolio Management

11

• Resource Management12

• Revision Control

13

For a data warehouse it would be common to use the following tools in the following way:

Project Management Software Most organisations either have a large centralised project management system such as Primavera P3 or desktop project management systems such as Microsoft Project. These provide the high-level Gantt charts and resource management. In the components outlined above it is most common to put the phases, milestones and activities into this type of tool. The detailed and changing nature of the tasks makes most of the tools unsuitable for the level of detail required. Also the tools tend to be inaccessible to those doing the work for a number of reasons:

• Organisations are unwilling to invest in licences for every team member. • Applications require a desktop/laptop install. • Developers are unwilling to engage in using a project management tool. • Project managers don’t share the plan with developers for fear of contradiction

about the proposed timescales As a result these tools are useful for holding the phase, milestone and activity level information but are rarely useful for task level information in data warehouse projects due to the large number of interlinking tasks required to manage the environment.

Ticketing

Ticketing systems are often used to track issues with software but their use can be much broader. Most ticketing systems allow the classification of tickets as well as dependencies between tickets and a workflow element that allows tickets to be assigned to others. A well-configured system is therefore the ideal tool for managing tasks, issues, risks, test cases, defects and individual enhancement requests. Tasks are initially raised; as the team member works on the task they may create dependant or sub-tasks (often as simple reminders to themselves or others). When issues arise they are captured against the task that is being affected allowing project

7 http://en.wikipedia.org/wiki/List_of_project_management_software

8 http://en.wikipedia.org/wiki/Project_management_software

9 http://en.wikipedia.org/wiki/Collaborative_software

10 http://en.wikipedia.org/wiki/Issue_tracking_system

11 http://en.wikipedia.org/wiki/Project_Portfolio_Management

12 http://en.wikipedia.org/wiki/Resource_Management

13 http://en.wikipedia.org/wiki/Revision_control



Page 16

managers to see what is impacting the project timelines. The same is true for the other ticket types (enhancement, risk, test case and defect). Deploying a ticketing system, and opening it to everyone involved in the project from business user to developer, allowing everyone to see everything, can have dramatic effects on the speed and quality of development. It is important that the culture around the system is one of mutual trust and respect. It is easy for a poor manager to go and count the number of defects in an individual developer’s code as a KPI of that developer’s performance. This is very naïve for two reasons: it discourages honesty and it does not measure performance at all. Discouraging honesty is a disaster, because the manager will never know the true state of the project again. The number of defects against one developer may be high because that person is the most skilled developer and therefore gets the most difficult work to do, because the specification was wrong, because the source system has changed, or because the requirements changed when the users saw the initial results.

14

An effective ticketing system will also highlight delays and bottlenecks in the process where, for example, critical blocking tasks go unanswered. Careful review of this information allows risks and issues to be addressed early, thus reducing impact and for an understanding of the root cause of delays to be gained which can be used to speed up subsequent phases. It also removes the process whereby the project manager each week goes around and disturbs everyone else on the project to get an update on the status of each task, which wastes huge amounts of time for those disturbed. A project manager can get the status from the system and then talk to those individuals whose tasks and issues have a material effect on the status of the project. This is management by exception rather than micro-management of the process.

Version Control A version control system is vital to the development of a data warehouse, not just for the code developed but every document used throughout the life of the project and subsequent maintenance. Whilst there are products especially built for document rather than code version control it is often sufficient just to use the same piece of software. The advantages of source code control have long been established but documentation control is often not addressed. If there is a requirements document on a shared drive that is updated when a new requirement emerges and (if the author remembers) the version number on the front page or in the file name is updated this does not mean that everyone working on the project has the same document. If someone copies it to their laptop to work on it at home over the weekend and on their return copies back to the shared drive all would appear well. The issue arises if two people have had the same idea, when the second person copies their work back to the shared drive the first person’s work is simply overwritten.

14

This is a failing in the requirements capture process that should be picked up by the project manager from these tickets and corrected



Page 17

Using a version control system also means that the development team can work against a fixed version of requirements for a period of time, even if others in the organisation are still updating the requirements. This stability allows the development process to be smoother and a gap analysis performed at a later stage to understand what has changes allows the developers to catch up with the requirement (normally in another phase). Finally the repository provides an auditable trail of the changes in all aspects of the project documentation that again can help with improving future phases.

Wiki

The introduction to this section described collaborative software that covers a broad swathe of technology. In practice the most useful software that one can use is a wiki. This provides a number of web pages that any user can update with a syntax that is simpler than standard HTML. The pages that get created are often part of the informal structure that helps the programme move along. Wikis can be used for frequently asked questions, staff lists, announcements, social events, guides to using other parts of the project, etc. Since they are a shared resource, editable by all they can provide a productive communication tool that is far more effective than email for encouraging collaboration. Wikis are more common than most people realise with websites such as Wikipedia using the same quick, cheap, easy software to build an encyclopaedia that can be deployed as the team’s main source of information for the project. It can also have the ‘water-cooler’ effect where people from IT and the business collect to share information in an informal manner rather than through formal documentation or review processes.



Page 18

Methodologies Most organisations will have a preferred IT development methodology. It is likely that the larger the organization the more structured the methodology (for example PRINCE2

15 or other

waterfall approaches). These processes are often assessed by mechanisms such as CMMI.16

Few large organisations are willing to adopt agile

17 approaches despite both the business

side saying that IT should deliver faster and meet requirements more completely and the IT side saying that they are trying to be flexible and meet that demand. As a result the organisations’ methodologies will not be well suited for the development of a data warehouse. This is because most methodologies have a fixed scope and a clear objective. The deployment of a new financial package covers certain well-defined business processes, has well understood inputs and outputs and bears scrutiny by use cases to examine the steps. A data warehouse is a system that will have a number of fixed outputs but also the intangible ‘just load up the data and I will know what I need when I see it‘ type requirement. It has a huge number of changing inputs from the source systems

18 and often has large parts that will

be in production whilst others are under development causing a crossover between the deployment and maintenance phases. Data warehouses are therefore inherently risky ventures and yet assessments such as CMMI set out to avoid projects that carry risk. In Peopleware

19 it suggests of CMMI assessments:

The projects most worth doing are the ones that will move you DOWN one full level on your process scale

Trying to deploy large-scale data warehouses in large organisations is what has lead to the concepts described in this document, whereby phases, milestones and activities can be managed within the organisation’s standard structures but allowing more agile development methods at the task level as well as detailed tracking of the relationship between issues and tasks which improves time and resource management. Remember that it is the deliverable and not the methodology used to get there that is important. It is all too easy to get trapped in trying to complete a methodology rather than the deliverable.

15

http://en.wikipedia.org/wiki/Prince2 16

http://en.wikipedia.org/wiki/CMMI 17

http://en.wikipedia.org/wiki/Agile_software_development 18

Imagine an organisation that has 25 source systems and two software upgrades/patches a year to each of them. This means that there are 50 changes a year or one a week to be analysed, designed, build and tested as well as

managing maintenance and other issues that arise. 19

Peopleware – Productive Projects and Team: Tom DeMarco and Timothy Lister, Dorset House Publishing, Second Edition 1999, Chapter 29: Process Improvement Programmes



Page 19

Project Leadership The single biggest impact on any project comes from the leadership it receives. Since a data warehouse is such a long-term commitment the leadership staff should understand that they are entering into a project that they may be engaged in for several years. A revolving door policy of leaders will only slow the project down. The project leadership comes in two parts:

• The sponsors: An executive sponsor and his delegate, the project sponsor, who commission the project and will ultimately, control its use.

• The project team: Leadership within the team normally consists of three individuals, a project manager, a senior technical architect and a senior business analyst who must work together to deliver, each taking responsibility for their own area but deferring to the others for their respective areas of responsibility.

The roles are outlined in more detail below:

The Executive Sponsor The Executive Sponsor is a senior manager or executive with demonstrable interest in the outcome of the project, who is ultimately responsible for securing spending authority and resources for the project. Ideally, the Executive Sponsor should be the highest-ranking manager possible, in proportion to the project size and scope. The Executive Sponsor acts as a vocal and visible champion, legitimizes the project’s goals and objectives, keeps abreast of major project activities, and is the ultimate decision-maker for the project. The Executive Sponsor provides support for the Project Sponsor and the Project Manager. They have final approval of all scope changes, and signs off on approvals to proceed to each succeeding project phase. The Executive Sponsor may elect to delegate some of the above responsibilities to the Project Sponsor (sometimes known as the Executive Sponsor’s Agent).

Project Sponsor

The Project Sponsor20

is someone who strongly supports the objectives of the project and is willing to act as a champion and advocate on behalf of the project. To this end they are the primary source of business input and take ownership from a business and governance perspective. This can be broken down into six main responsibilities:

• Accountability The project sponsor is responsible for holding the project manager to account and consequently keeping the project on track. The project sponsors must also make themselves available to provide support and address risks and issues.

20

Adapted from:

http://www.stanford.edu/dept/its/projects/PMO/files/linked_files/guidelines_sponsors.pdf

http://ithelp.lincoln.ac.nz/site/story_images/3021_project_sponsor_s8869.pdf http://www.cit.cornell.edu/computer/robohelp/cpmm/Project_Roles_and_Responsibilities.htm



Page 20

• Strategic Fit Assure that the project is aligned with the organization’s strategic goals.

• Resources Provide or locate resources for the project especially where these are outside the control of the project manager and protect resources from being pulled away.

• Project Finances Provide or locate funding for the project and track the budget in conjunction with the project manager.

• Lead Political Charge Help the project manager navigate the organization’s political environment.

• Own the Final Product Be clear on what is expected in the end and help celebrate & transition.

Project Manager

The Project Manager is the person responsible for ensuring that the Project Team completes the project. The Project Manager develops the project plan with the team and manages the team’s performance of project activities. It is also the responsibility of the Project Manager to secure acceptance and approval of deliverables from the Project Sponsor and other stakeholders. The Project Manager is responsible for communication, including status reporting, risk management, escalation of issues that cannot be resolved in the team, and, in general, making sure the project is delivered in budget, on schedule, and within scope.

Technical Architect The Technical Architect is the single point of responsibility for the technical solution from an application and system perspective. The main responsibilities of the Technical Architect are to:

• Define the technical architecture • Solve technical issues • Ensure that all components of the technical architecture are properly integrated

and implemented • Define the development tools and environment • Coach the technical team in the development of the technical architecture • Provide technical support and technical quality control throughout all stages of

the project • Co-ordinate vendor services related to technology selection and

implementation • Work with the Senior Business Analyst to determine how the technology can

be applied to meet the business needs • Work with the Project Manager to ensure the smooth running of the project • Evangelise the technical solution to the rest of the IT community and the

business



Page 21

Senior Business Analyst

The Senior Business Analyst is responsible for:

• Analysing and Defining the business requirements and solution • Quickly and clearly understanding the business issues and data challenges • Identifying the organization's strengths and weaknesses and suggesting areas

of improvement. • Reviewing and editing requirements, specifications, business processes and

recommendations related to proposed solution. • Leading the testing efforts • Working with the business to identify required changes • Communicating the required changes to the development team • Work with the Technical Architect to determine how the business need will be

met by the technology • Work with the Project Manager to ensure the smooth running of the project • Evangelise the business solution to the rest of the IT community and the

business

Leadership Style

Managing a small team to develop a large complex environment requires a degree of skill and the ability to adjust the style of leadership to match the situation. This type of flexibility is known as situational leadership and is a necessary quality in a data warehouse project.

Kenneth Blanchard wrote

21 “... managers

should work for their people, ... and not the reverse. ... If you think that your people are responsible and that your job is to be responsive, you really work hard to provide them with the resources and working conditions they need to accomplish the goals you've agreed to. You realize your job is not to do all the work yourself or sit back and wait to 'catch them doing something wrong', but to roll up your sleeves and help them win. If they win, you win.”

As staff develop on a data warehouse project it is typical for a good leadership team to move from a directive style through the coaching style and supporting style and ultimately reaching the delegating style. For example the technical architect may start with ‘Build the data warehouse this way’ moving through ‘We build the data warehouse this way because …’ and ‘I like what you have done but have you considered …’ and ending with ‘Thanks, that’s just what I envisioned’. To this end a strong relationship and shared vision between project manager, technical architect and senior business analyst is essential.

21

"Leadership and the One-Minute Manager", Kenneth Blanchard, Patricia Zigarmi, and Drea Zigarmi, p18. This is a

refinement of Path-Goal Theory developed by Robert House in 1971

Supporting

Coaching

Delegating

Directing S

up

po

rtiv

e

Be

ha

vio

ur

Directive Behaviour



Page 22

Organisational Learning

Most people working on a project will learn in some way, but this knowledge, locked away in an individual, is of little value to the business as a whole. The team have to become a learning organisation that actively creates, captures, transfers and mobilizes knowledge to enable it to adapt to a changing environment.

22

“Knowledge is not knowledge until someone else knows that one knows.”

23

For a data warehouse project organisational learning is critical, as, not only is the environment rapidly changing but the number of places from which information is sourced is larger than any other IT project the business is likely to engage in. In this context information is more than data being transferred inside systems, it also includes information about how business processes work, key contacts both inside and outside the organisation, critical business requirements, data quality issues, etc. Organisational learning is a cultural phenomenon that requires team members to actively participate in developing knowledge. To this end a ticketing system, wiki and document versioning system provide tools but it is the people who have to engage in the concept and as a result be willing to:

• Share information in a timely fashion • Capture even the most incidental information • Provide access to work in progress • Be open about issues and mistakes • Submit everything to a rapid peer review processes • Re-use rather than re-invent • Research and capture research for others to use • Have largely unrestricted access to the entire project knowledge repository • Accept change as inevitable and be prepared to adapt

A team that has a culture capable of organisational learning will be:

• More productive because they have the information to do the job • Happier because they are learning and their contribution is recognised • Less prone to expensive re-work as issues are addressed earlier

All of this leads to faster, more successful projects.

22

http://en.wikipedia.org/wiki/Organizational_learning 23

Gaius Lucilius c180Bc-103BC



Page 23

Team Rotation It is common practice for the most experienced developers to be put in change of major enhancements and then in a sliding scale of experience to assign people to maintenance work and issue resolution. This has initial benefits of getting the best developers to do the largest chunk of work but projects can also benefit from rotating people so that after the enhancement is developed those resources move to the issue handling and other developers move up to maintenance from issues and to enhancements from maintenance. This has a number of very positive aspects. Firstly the most skilled developers have done the first development, and have therefore laid down the principles and standards for future development that the others will follow. By moving these people into issue handling they also become aware of the consequences of their work and any quality or design issues that have been introduced. For the other less experienced teams they see career development as they can learn new skills and have an opportunity to show that they can move up to the next level. If problems occur they can still be supported by more senior developers but it is better to allow people learn early. This practice is also helpful in staff retention because it creates varied work and an opportunity to learn. It also means that people will work across subject areas and therefore have a greater understanding of the whole. This in turn makes it easier when individuals do leave as combined with the organisational learning discussed above the team is greater than the sum of its parts.



Page 24

Estimating and Effort Initial estimating on a data warehouse project will always be very subjective and therefore wrong. Plans will often start with what the developer feels is required (and therefore very high) and then adjusted down to meet what the project manager feels is acceptable (and therefore very low). The final value will be somewhere between the two. It is important that everyone understands that the timescales will change in light of experience. Subsequent re-assessments of effort will become more accurate if the organisation is willing to learn. This is often done by the organisational learning process described above, combined with end of milestone or phase reviews and detailed reviews of the ticketing system – what issues arose, will similar issues arise in the next development and how to allow or compensate for them. Tasks are also non-uniform, some tasks will take a short amount of time – often those at the start and the end of a phase, others will take a longer period – often those in the middle of the phase.

24 Project monitoring systems that determine completeness by the number of tasks

complete as a percentage of the total number of tasks will see the project initially getting ‘ahead of schedule’ before ‘falling massively behind schedule’ and finally ‘recovering some of the lost time’. This is exacerbated by the fact that if a ticketing system is used additional tasks will be created and therefore the percentage complete will appear to drop at some points in the project. Better measures are around the ratio of tasks to issues and the completion of activities to planned activity duration. Agile and other similar methodologies provide several techniques for improving the estimation. The first of these is velocity

25 (or sometimes better known as load factor). This is the ratio

between the developers’ estimate and what is actually achieved. So if a task is estimated as taking 4 days and then takes 10 days the “velocity” is 10/4 or 2.5. For the next phase the developers’ estimates are taken and multiplied by 2.5 to determine the likely timescale. The velocity is measured for each estimate and whilst initially it will oscillate widely after a few iterations it will settle to a factor that can regularly be used calculate elapsed time. The accuracy comes from allowing for two factors. The first factor is the developers own tendency to over or under estimate the effort required to do any given piece of work. The second factor is the distraction that the work environment provides with telephone calls, e-mails and meetings, etc. These work distractions usually have an organisation specific pattern that is not normally factored in by developers but needs to be consistently applied to plans Over a period of time developers will come to understand their own estimating and their velocity will tend to a constant. The consistency of this number is what allows project managers to be able to estimate accurately. Agile development processes also introduce the concept of technical debt

26. This is the

obligation that an organization incurs when it chooses a design or construction approach that is expedient in the short term but that increases complexity and is more costly in the long term.

24

See the Data Management & warehousing white paper “How Data Works” for a discussion of volume vs.

complexity in data and how this affects the timescales in a data warehouse project. 25

Version One discussion of Velocity: http://www.versionone.com/Resources/Velocity.asp 26

First proposed by Ward Cunningham in 1992 at the OOPSLA92 conference (http://c2.com/doc/oopsla92.html)



Page 25

Technical debt can occur accidentally (when a mistake is made) or deliberately (when a conscience decision is made to put something off). The secret to a successful implementation is to continually work to manage and reduce the debt, just like debt in real life. It is technical debt, so often unaccounted for, that often derails large projects as they run out of resource and don’t understand where it has gone. Debt can be classified just as in real life financial situations:

• Debt incurred un-intentionally o Usually due to low quality work (the uninsured loss)

• Debt incurred intentionally o Short-term debt, usually incurred reactively, for tactical reasons such as

numerous tiny shortcuts (credit card expenditure) o Medium-term debt incurred by individually identifiable shortcuts such as the

creation of a tactical data mart (the car loan) o Long-term debt, usually incurred proactively, for strategic reasons such as

the delay in purchasing significant technical infrastructure (the mortgage) • Non Debt

o Some things are not technical debt such as feature backlog, deferred features, cut features, etc. Not all incomplete work is debt. These aren't debt, because they don't require resource to correct them (the interest payment).

Debt requires re-payment with interest, i.e. whatever has been done has cost something (the debt) and correcting it requires additional resource (the interest) to put it to how it should be. As in financial circumstances delaying repayment always costs more in the long term.

27

It should be noted that a well-defined technical architecture as discussed above is needed in order to identify technical debt. This is because there must be a blueprint and baseline against which to draw comparisons against. This also re-enforces the need for a simple architecture as measurement is more difficult against complex architectures. It is often thought that time-boxing project phases either cannot be done for data warehouse projects or will force developers to deliver something. Neither is true. A time-boxed project will deliver something but can incur technical debt for those things that get omitted or compromised. The delivered solution may be of little value if the time allowed is insufficient. If the techniques described above are employed then early phases should be run as scope or benefit driven rather than relying on time boxing. As velocity and technical debt are better understood in the environment the project can switch to time-boxed activities to allow the business to see tangible time-scaled development and deployment roadmap. Finally the project manager must understand the cost of their actions. By putting good communication, processes and systems in place the project manager can effectively monitor and manage a project by exception, allowing the senior business analyst to handle the business aspects and the technical architect to manage the technology and together progress the delivery. If a team of eight people is brought together once a week for a two-hour status meeting with the project manager, then two working days out of the forty working days (eight people for five days a week assuming eight hour days) available in the week are lost. That weekly status meeting reflects 5% of all the available resource!

The ultimate management sin is wasting people’s time28

27

Note: The original draft of this paper was written before the 2008 financial crisis. The failure to manage debt in the real world caused significant institutional melt down. This is mirrored by the meltdown of large data warehouse

projects within large organisations that have failed to manage technical debt. 28

Peopleware – Productive Projects and Team: Tom DeMarco and Timothy Lister, Dorset House Publishing, Second Edition 1999, Chapter 33



Page 26

Tips and Tricks The following section lists some items that are useful for a project manager to remember. It is not exhaustive but provides some high level reminders:

• Phase 1: Mobilisation Setting up a project has a cost, having a Mobilisation phase allows time and resource to be allocated to the setup. If there is no allowance for it then at the end of the first phase the cost of setup will be at least equal to the delay in the delivery of the phase.

• Team Members Wiki Page

If the project has a wiki (which it should) take photographs of everyone and add them to a page that has everyone on it, order it alphabetically by first name rather than in any organisational structure, include their contact details. This is again something that makes people feel involved and is a useful resource when someone remote to the core team or a new starter wants to contact another member of the team.

• Develop a no blame culture

Mistakes happen – they come from a lack of understanding or knowledge or poor communication and everyone on the team will make them at different times. It is therefore important that people are willing to admit to their mistakes and learn from them and that the project manager understands why mistakes are occurring and then take corrective action (e.g. training, improved communication channels, etc.) Where mistakes are hidden there is a build up of issues and technical debt that appear, inevitably, at critical points in the project.

• Large Teams & Parallel Streams

Avoid large teams and large numbers of parallel streams of work. Data warehouses are complex intertwined systems and the impact of a large number of teams trying to work simultaneously across the system will out-weigh any benefit from parallel working. Parallel teams work where there are discreet non-interacting areas, otherwise the contention between components and resources becomes too much of an overhead. Also as a team gets larger the degree of effective communication within the team drops. The balance is to have sufficient people to do the work and yet few enough to ensure effective communication between them.

• Transparency

By default let everyone involved with the project see everything. Exceptionally restrict access to sensitive documents. Always challenge any request to categorise a document as “sensitive”. This helps for many reasons; delays are not a sudden surprise to users, others on the project often volunteer help or expertise about issues in unexpected areas, it develops an inclusive aspect to the team dynamic, it provides an opportunity for people to learn from the work of others, etc.

• Document and version everything

As this document has discussed, having a ticketing and version control system in place makes management of a rapidly changing environment possible. No individual or group of individuals can effectively manage all the tasks, risks, issues, changes and documents of a large project with manual systems and if the system is easy to use then documenting everything is preferable to trying to decide what might be needed in the future.



Page 27

• Use Storyboards but avoid Use Cases

Many formal methodologies for OLTP systems have use-cases29

that describe how a user must get through a system. This is fine for such solutions where a pre-defined path is essential. For a data warehouse the individual use case is irrelevant as the user is unlikely to follow the same route regularly. Instead a story is required that talks of a user being asked to produce a specific report and then having to do analysis of another set of data and incorporate it in the results, etc. The storyboard should describe the process of moving around the system but not prescribe specific routes for users to take, instead focusing on how to transition between aspects of the system.

• Key Design Decisions Whilst the idea of documenting everything has already been described it is particularly important to document key design decisions such that when a problem occurs it is easy to follow the intended route rather than revert to a re-evaluation of possible solutions.

• Manage Technical Debt

Ensure that everyone can quantify the cost implications of the decisions they make and document them in such a way that the project can assess the technical debt they are accruing and schedule the debt reduction appropriately.

29

“UML Distilled” Martin Fowler “The more I see of use cases, the less valuable the use case diagram seems to be. With use cases, concentrate your energy on their text rather than on the diagram. Despite the fact that the UML has nothing to say about the use case text, it is the text that contains all the value in the technique.”



Page 28

Summary Data warehouse projects pose a specific set of challenges for the project manager. Projects often have poorly set expectations in terms of timescales, the likely return on investment, the vendors’ promises for tools or the expectations set between the business and IT within an organisation. They also have large technical architectures and resourcing issues that need to be handled. This document has outlined the building blocks of good project control including the definition of phases, milestones, activities, tasks, issues, enhancements, test cases, defects and risks and discussed how they can be managed, and when, using an event horizon the project manager can expect to get information. To help manage these building blocks this paper has looked at the types of tools and technology and how they can be used to assist the project manager. These tools include project management software, ticketing systems, version control and wikis. It has also looked at how these tools fit into methodologies. The final section of the paper has looked at how effective project leadership and estimating can improve the chances of success for a project. This has included understanding the roles of the executive sponsor, project manager, technical architect and senior business analyst along with the use of different leadership styles, organisational learning and team rotation.



Page 29

Appendix 1 – Governance Procedures Each organisation will create its own processes for the governance of the data warehouse project. Data Management & Warehousing have defined and used processes in three major groups:

• Change Management Processes Identifying and controlling enhancements, maintenance and issues with the system

• Data Warehouse Processes The processes associated with the build and deployment of the data warehouse itself

• Data Management Processes The processes associated with the management of the data held within the data warehouse

Outlined below are the major components of each of the processes. These are given as examples only and are shown only with the high level summary diagrams and short descriptions as indicators to what should be developed by an organisation to service its environment

Change Management Processes

Enhancements and maintenance processes are required to ensure the communication of the organisation’s requirements of the data warehouse and to ensure that those requirements are costed and prioritised in such a way as to deliver maximum benefit.

The issue management process is required to ensure that all issues found with business intelligence outputs are captured and resolved consistently, allowing for KPI capture and process visibility for active management.



Page 30

Data Warehouse Processes

The requirements process is required to ensure that the user requirements are met effectively by creating a statement of what is required and a process for changing the definition of what is required

The enhancement request packaging process is required to ensure that the scope is limited to user requirements that deliver benefit at reasonable cost and project timescales are predictable.

The ETL design & build process is required to ensure that a reliable, robust, accurate and performant data loading process is designed and build.

The report design and build process is required to ensure that a reliable, robust, accurate and easy to use reporting solution is designed and build.

The testing process is required to ensure that the solution is a robust and accurate reflection of the requirements; that changes and issues are handled promptly, and performance is adequate.



Page 31

Data Management Processes

The data quality process is required to measure, control and improve the quality of data held in the data warehouse, reacting to new issues quickly and ensuring source systems are responsible for the data they provide.

The data model process is required to develop and maintain both the logical and physical data models against set standards, and aligned with metadata.

The data lifecycle process is required to give structure to the adding and removing of data from the data warehouse, and maintaining a balance between business, hardware, cost and compliance considerations.

The data security process is required to ensure that the organization complies with legal requirements related to data protection, and that the data warehouse complies with all the organizations' internal data policies.

The metadata process is required to ensure that metadata is captured consistently as part of the data warehouse development, such that it can be effectively used in applications including data quality checking, data profiling and data security.



Page 32

Appendix 2 – Project Services Data Management & Warehousing have a web based project management service configured for the development and management of data warehouses. The solution provides a complete environment including version control, ticketing, wiki and many other features using free, widely available, open source software.

A full description of the service can be found at: http://projects.datamgmt.com A demonstration system can be found at: http://projects.datamgmt.com/demo The Data Management & Warehousing internal project management (screenshot above) can be found at: http://projects.datamgmt.com/datamgmt A description of how to build the system on your own server can be found at: http://projects.datamgmt.com/howto The company also hosts the service for clients who require a fast start on their projects.

Copyright © 2008 Data Management & Warehousing. All rights reserved. Reproduction not permitted without written authorisation. References to other companies and their products use trademarks owned by the respective companies and are for reference purposes only. Some terms and definitions taken from Wikipedia

Date post:	15-Nov-2014
Category:	Documents
Upload:	davidmwalker
View:	14 times
Download:	1 times

White Paper - Data Warehouse Project Management

Documents