As promised in my earlier blog post, here is Part 2 of How A Challenging BI Project Succeeds. In my first post, I discussed our many challenges. This post will focus on how we overcame those challenges. Simply put, we were successful because of solid project leadership, talent, and process (discipline). Let us walk through each factor.
Solid Project Leadership
I am a strong believer that project leadership and management are crucial to project success. The success of this project certainly reinforced my beliefs! Four aspects of solid project leadership that were crucial to our success were:
- A no-excuses mindset
This was probably the most important mindset instilled in the team. In a project that had tight deadlines and high visibility from the client, the “no-excuses” mindset was important (and necessary for accomplishment). There were several instances when we had to get things done with limited resources and other constraints. Our leadership team gave us the freedom to think creatively on how to manage these constraints, but didn’t allow us to create excuses on why it couldn’t get done. A no-excuses mindset is powerful not only in project work, but also in life. We can always come up with excuses on why we cannot accomplish something. Changing your mindset to not allow excuses makes a great difference. This mindset forces you into “problem-solving” mode where you figure out options that are available instead of getting into “excuse-generation” mode. The mindset shift is not easy and can be terribly frustrating. However, the outcomes are very satisfying!
- An environment where the Technical Leads had freedom to make their own decisions
This was probably the best thing about the entire project and the reason I enjoyed working on it so much. As Dan Pink noted in his book, Drive, autonomy is important for motivation and exceptional performance. I can hardly think of any instance where leadership overruled any decisions I made or second guessed what we were doing. They were supportive but not overbearing.
- Freedom balanced with accountability
Freedom does not work very well if it is not balanced with accountability. Freedom did not mean the lack of status meetings or probing questions. We had weekly status meetings and communicated regularly throughout the week. Our leadership team had a knack of asking great questions to determine if there were any underlying risks or problems that the team had to be address.
- Calm confidence
The most important thing you want from your leadership is calm confidence especially on what could have turned into a stressful project.
It was no secret that our project team had rock stars! Although I am biased, I am sure everyone would agree that the team made this project feel like a walk in the park. Two aspects that set this team apart were:
- A great attitude
The best part about our team was the great attitude each one of them exhibited during the course of a challenging project. I believe that talent without attitude is not a great recipe for success! As with any project of this size and scope, there were several small and big surprises. When we changed course, the team would take it in stride and immediately get working on the new task.
- They took ownership, not responsibility
Responsibility and ownership are two different mindsets. You can take responsibility for a particular task or outcome and probably do just enough to complete it. Ownership is much different. You start caring about the process and the end-product. You will chase down any roadblocks along the way to ensure that tasks get done on time and get done right. The team on this project chose ownership above responsibility.
The team led detailed analysis during the requirements phase. We would go to great lengths to understand the CDS data warehouse to ensure that our understanding was accurate. We would be the first to figure out data quality issues in the warehouse and report them to the client. There were various occasions that the client mentioned that we had a better grasp of the data model than they did!
Process was an important factor in our success. Our process manifested in the following ways:
- Our requirements definition process was thorough. We created detailed data flow diagrams for existing procedures to ensure that our understanding of the data warehouse process was correct. These data flow diagrams were reviewed by the team and the client. We also created data mapping documents for each report. We followed up with the client regularly to ensure that our documentation was reviewed. Requirements documents were updated throughout the lifecycle to reflect “current realities”. It was not a one-and-done effort. We posed several questions to the client during our requirements definition phase to ensure that mappings were accurate and we didn’t introduce errors early in the phase.
- We were very rigorous with our unit testing efforts throughout the lifecycle. We ensured that unit testing code could be executed with the click of a button. We tried to reduce manual steps while running unit test code as this would defeat the purpose. The client praised us continually on our code and flawless response times.
- We had regularly scheduled code reviews with the client and internal code reviews within the team. Code reviews were very beneficial as we were able to find defects earlier in the process.
- We were very thorough with our design. We created both data and process flows for all our load processes. The team updated the design continuously to reflect changes made to improve performance.
Communication was the “glue” that kept this project on track. In a project with various stakeholders and a large team, communication had to be done right. From the beginning we set clear expectations on what we would deliver. We held weekly status meetings with the client and individual stakeholders, but also made sure we communicated any issues immediately with the client. Having a co-located team that worked on the same floor helped a lot!
I wish I could say that we figured everything out during the project and anticipated all roadblocks, but that wasn’t the case on most occasions! We figured things out as we went along. We got really good at anticipating problems by doing an initial pilot release. I also had to run several “performance experiments” to ensure that our load performance and retrieval performance was good.
The lesson here is that it’s important to stay curious and try different things instead of just throwing your hands up.