From my vault of old files.
This is very much a beginners edition – filled with my own personal opinion.
1. Having a “signed off design” is useless. In the rare scenario that the client has agreed that any change in the design will be a change request, congratulations you win! Your project will never finish.
2. Data quality will have an impact even when it’s “not in scope”. If when you mention data quality your project manager says “that’s not in scope”, sack them. Only if the business sponsor agrees that the solution doesn’t need to be tested, and that the integration or reporting components are allowed to fail without any explanatory error message if one potential explanation is that they have encountered unexpected data, is data quality “out of scope”. You need to answer the question “how do we detect and / or handle bad data?” and even if the answer is “we don’t” it’s still in scope.
3. Sometimes data isn’t available. If you want to scope your product at all you at least need to constrain the source systems. As soon as you do this – I.e. Limit you scope to less than all of the data in the world – there is a risk that the required data isn’t available. You should assign ownership of this risk and understand how the scenario will be funded.
4. There are only 8 types of products you are building: interfaces, one data acquisition frameworks, one “consolidated” data store, reports, cubes or equivalent, derived data logic, and data-marts, process support frameworks. The whole project team needs to know what these are (feel free to use more precise language to the point that the whole project team can still relate to it). The project manager is part of the project team.
5. If you don’t know how many of the above products you expect to build or update when you estimate your product you will fail. If you don’t know specially the names of each during each phase gate, status report, or iteration kick-off – you will fail. It is however, okay for these to change – in a controlled way. It’s likely that sometimes building an additional report doesn’t change the scope of the project. In fact, sometimes it’s a compromise you have to sell.
6. By the way, a “process support framework” is a framework that supports a process. These include meta-data management framework, data quality framework, semantic layer, business glossary, etc. If you have any of these in your solution, and don’t have equivalent business owners for the process components of each, you will fail. Don’t pretend you are using these unless you really have a plan to implement them properly. Ask your solution architect if these are part of your solution and unless they are also in your plan you need to consider taking them out and planning for re-work.
7. You must be able to answer the question “if we had this data, where would it be?” Which means a single consolidated data model linked to source systems and derived data logic. Use this model to track the status of your integration build – field by field.
8. Don’t skip data profiling and the related q&a sessions to understand the results. 80% of the data profile reports will be a waste of time. The rest will be valuable but likely require somebody to go and talk to the call centre, check an asset sticker, or open the operational system it came from.
9. Status reporting must include the following: status of each product(started, on hold, tested, accepted, etc), status of data quality issue log, status of data profiling and q&a log, status of the data model implementation and data availability.
10. If does not matter if the stakeholders don’t want to see the above level of detail. That is the detail required to understand where resources need to be allocated. You need to make them understand why it’s important.
Bonus tip #1o. If your project manager complains that the above list is from somebody who “doesn’t understand project management” – sack them.