Tips on how to effectively complete an analytics project without the dreaded overages that can often accompany the endeavor.
Anyone that has implemented or oversaw a business intelligence initiative can attest to the feared point when the phrase “We’ve got a week left…” is uttered. Moral drops and stress goes through the roof. Though it may not be intentional, this is when fingers get pointed and blame begins to be thrown around as to why the project was not finished within the budgeted time frame.
I could list out a million reasons why this happens, but that isn’t really the purpose of this post. Instead, I have a few tips on how to effectively complete a project without the dreaded overages that can accompany them.
For a BI Project of any size, the tendency to add additional features to make a robust solution into an all-encompassing solution will be ever present. The natural outgrowth of any IT project is finding an organization’s previously unknown deficiencies that were not considered during the proof of concept or planning/designing phase.
As beneficial as it would be to fix them now or add them to the current set of requirements for a project, there should be heavy resistance to incorporating the requests. There is nothing wrong with logging these newly discovered needs and adding them to a backlog for future projects, but unless they are absolutely critical to completing the project at hand, ignore them until a later date. This includes additional enhancements or modifications requested by business users or other stakeholders that are not mission critical for the project to cross the finish line.
Most projects will start out with a discovery phase that transitions into a planning portion. Use this time before the project really kicks into gear to work with the development team to gather their thoughts regarding estimated time required for various tasks and objectives. After all, someone who handles the coding and back end data modeling work may have no idea how much effort goes into creating a user interface that will utilize that data. Although it sounds like common sense, it bears repeating: it’s always best to consult those that will be doing the work.
Additionally, the most difficult aspect of setting a realistic timeline is to plan for the amount of time a task will take when all of the variables involved are not known. When a development team member hasn’t performed a certain task in the past, or a team member is unsure of the amount of effort a certain task will require, that is OK. There is never 100% certainty when estimating timeframes. This is why it is essential to add “buffer time” to an account for any unknowns that can come up during development. It is always better to have additional time for the project planned up front than to go back and ask for more at the end.
As a general rule of thumb, I always have team members estimate double the time they think a task will take if they haven’t actually done similar work before. If they finish before the allotted time, great! If they go over, the addition of the extra time baked into the estimate will buffer some of that overage.
The days of a project team being handed tasks and told to work on them independently until everything is finished occur far less often than in the past. The “Waterfall Development” approach to project work has its merits, but it usually seems like short iterations tend to produce much more robust results and high user adoption.
Assigning tasks to team members to accomplish in a week or two, and then meeting on progress after that time, forces issues to surface and be dealt with quickly. Coordinating weekly or bi-weekly team meetings to review progress and discuss the next steps keeps everyone in sync and up to date on the status of the project as well.
Time and time again, I have seen project teams talk through problems and come up with creative solutions that no individual would have been able to come up with on their own. This type of team work helps keep project momentum going and ensure there isn’t a stall in progress.
Incremental progress is also good for team moral. By breaking down the work into these shorter iterations, it allows the team to see the actualization of the original requirements throughout the duration of the project.
This seems fairly obvious, but time and time again project team members get pulled in too many other directions while trying to complete work on a project. When this happens, the team can lose the momentum they built up and progress can significantly slow.
Working with management and planning for team member time is key to ensuring that individuals staffed on the project are able to see the project through to completion. If a team member is placed on more than one project concurrently, plan for that time up front during the initial planning phase of the project. It always takes far more time to onboard a new resource than maintain one throughout the project lifecycle.
One of the most difficult steps of a project is getting concrete requirements from the business. This isn’t the fault of the business users, stakeholders, and product owners, but due to the fact that they cannot always anticipate everything the project will need to address before it starts.
There are entire books written on effective requirements gathering, so I won’t delve into that here. But, when the project team does receive requirements:
If fluid communication between the project team and business continues throughout the project, the risk of rework will be greatly minimized.
This also goes hand-in-hand with breaking the project down into shorter iterations so that the team can involve the relevant business users/stakeholders regularly to show what they have accomplished. It keeps the business excited about the end result and begins to get buy in before any final release is pushed out.
The above tips may already be followed in your organization but make sure to take a step back and evaluate how well the current project is running.
These tips are by no means an inclusive list, and there are hundreds more that are just as helpful, but these are a few that I’ve observed which have helped teams deal with issues that arise during a project. IT projects vary widely with regards to requirements and goals, and there is never an end-all-be-all list of ways to effectively complete a project.
By mitigating feature creep, setting a realistic timeline, keeping work focused with short iterations, ensuring a dedicated staff, and adhering to project requirements, you can ensure your project stays manageable, remains under control, and gets delivered on time.