P2P

12 P E E R T O P E E R : I L T A ' S Q U A R T E R L Y M A G A Z I N E | S U M M E R 2 0 2 2 written in a factual sense designed to convey specifics to members of a technical team. It is necessarily more granular and engineering-related than a requirements document, and something one would not expect end users to be able to easily digest (although hopefully some power-users might be able to do so – if so - this increases the likelihood of project success). All in all, functional specifications should also serve as a backbone for the development of a strong project plan for the effort, something defining discrete tasks, required resources, proposed timing and all the other typical elements of a well- constructed plan. • Budget / Project Plan It is always a best practice to create, track and update/alert users on the status of a budget or overdue project plan. It's hard for anyone to sign off on something significant (e.g., a home or vehicle purchase, renovation, new job) without specifics and details, and legal tech projects are no different. Budgets should be prepared prior to the outset of a project and continually maintained and made available for stakeholders at various project milestones. • Measurement / Holding The Gains Most projects have (or should have goals, with some common objectives being cost savings, revenue gains, process improvements, staff reduction, etc. Ensuring that a project manager is committed to revisiting projects at an appropriate time interval post-implementation (which could be days, weeks or months depending on the effort), it makes good sense to be sure the intended benefits are truly being realized. It is far from uncommon for projects to be seemingly completed yet the overarching goals to remain unachieved. Embedding - Strategy To Best Define Requirements Natural Gap Between Business And I.T. To state what is – to me at least - quite apparent, there is typically a natural detachment between the technology function and virtually all operational departments. For the most part, individuals with expertise in database design, programming or problem resolution are not going to spend their days worrying about sales forecasts, logistics considerations or financial results (except perhaps for those related to their FAANG stock investments!). It's fair to say the lack of understanding is a two-way street as well. Many working in a line function sometimes consider those who assist with technology as their "IT Guy", a resource who is on site to deal with whatever their problems of the day might be. The problem is, as F E A T U R E S "All in all, functional specifications should also serve as a backbone for the development of a strong project plan."

• Cover