sanchitar17

Project Charter is the launchpad of a project and a typical project doesn’t move ahead without it. It’s the first artifact that needs to be drafted so that projects can be prioritized and establish resource loading. It is living document, as the project matures typically 10-15% of the elements are further defined or refined.
The importance lies in its key elements which covers the below:
Business Case: explains why something needs to be done “now” Opportunity Statement or Problem Statement: explains the opportunity or the defect that need to be addressed and benefits associated with such improvement Goal Statement: defines the quantified objective of the project and by when Project Scope: defines the project boundaries Project Plan: phase wise timeline for the project to be completed Team Selection: Selected team members are assigned responsibilities  
Now if this charter is not created for a project and a project is initiated by a Project Lead, there would be several risks as outlined below:
There would be risk of management focus on the objectives and outcomes if charter is not created and signed off. Rationale for the project would be questionable eventually Strategic sense to address the problem may not tie up and loose traction There can be risk of the project becoming counter-productive if relevant business issue is not selected and the charter is absent Significance of the problem may itself be low and without a charter there would be risk of agreement of the project need Cost of project may be higher than targeted benefits and questioned later if a charter is absent Risk of absence of Charter with defined timelines may result in low traction and prolong overall timelines Project scope creep may arise, what’s included and what’s excluded should be clear and present on the charter Resources may be unavailable or inadequately available if right resourcing is not done and mentioned in the Charter. The resource load should be clearly communicated with Stakeholder and Champion for sign off. We may also run a risk of “inappropriate” resource for the project which may impact all deliverables We would also run a risk in delayed decisions of solution implementation due to absence of charter There can be a potential regulatory issue if a project is headed in a direction the charter for which is not agreed by the management and the business priority happens to be regulatory issues There can be delays which may occur due to absence of an agreed charter, the consequences can lead to penalties/legal actions. Management may single out project lead for not documenting and obtaining sign-off of a Project Charter The absence of charter may lead of unavailability of information when needed, thus impacting not just the timelines but accuracy of analysis There can be serious data privacy issues if a signed off Charter is absent; there can be instances of use of data sets that are confidential and unauthorized access/use may lead to contractual breaches in case of client-vendor business model There can be a risk of project duplication if a charter is not created and signed off. Further to the above, if project is run without Charter, there is a risk of “no- recognition” for the project itself and team, despite following the right rigor and analysis  

As LSS professional often we find ourselves in a tight situation and complete deliverables under pressure. There is a chance that due to several external factors around us we end up Data dredging, also referred as "data fishing" which means analyzing data in such a manner so that possible relationships between data are somehow demonstrated. The effects are harmful because it defeats the purpose of true hypothesis testing. Some of the other terms of data dredging are “p-hacking”, “data snooping”, “fishing trip” and so on. For instance, we want to prove a hypothesis during a pre-project and post project improvement analysis, however the data doesn’t reveal so and we use a “cherry picked” sample which helped prove the point of improvement statistically. This would result in data dredging!
In LSS world, unless factors are statistically significant, it doesn’t have the “value” and to prove the hypothesis using a statistical test quickly may end up in data dredging. Sometimes, unintentionally; more often a move made to close the case with some bias. It is easy to access large data set and perform analysis to come up with various relationships at random. Sometimes, data dredging may result in accidental correlation which otherwise may not have been identified. However, in our endeavor to research/analyze, it is important to recognize a valid relationship and focus on unbiased data set to arrive at accurate conclusions.
The end results can be harmful in many ways:
·         Proved a hypothesis as statistically significant which may be later be proved as ‘not significant’
·         Solutions are framed around a “so-called” significant cause whereas it may not help resolve the issue thereby becoming a questionable move later
·         Time/Effort spent would be a waste and end up being anti-LSS (Lean says reduce waste!)
·         Credibility of the professional may go down if practiced frequently and may put the entire organization in the wrong spot
 
We can avoid data dredging by adopting practices like:
·         Ensuring data set is sufficient, relevant, representative, and not just a mere “subset”
·         Negotiate for adequate time, effort required for analysis and not perform under pressure, if we must turn around something quickly, we do so with a caution statement and not conclude too soon
·         Make data capture process accurate, robust, and exhaustive
·         Question the extreme values
·         Go with a balance of “data door” and “process door” approach in the project so that all possibilities are explored, and data/information are better presented for operational consumption without getting stuck in hypothesis testing
·         Keep it simple, use business sense as well to justify causation once we see correlation
A scenario: The project lead shared the following data towards the end of project end for a review with the mentor:
Pro-Project (AHT in mins)
20
Post Project (AHT in mins)
13
 
A better view for the project mentor would be the below table to mitigate data dredging as assess sustained performance:
Pre Project
(AHT in mins)
20
16
23
22
18
24
17
Post Project
(AHT in mins)
12
16
13
12
14
13
11
Response is drafted basis relevance of Data Dredging typically in business process outsourcing.