Don’t Let Death by Committee Sidetrack Your Service Desk Project Plan
When it comes to implementing a service desk project plan, what’s set on paper by all interested parties ideally should be reflected in the final work product. The reality is that such long-term goals are frequently prone to revision, second opinions, and second-guessing, or shifts in the organizational structure and roles may also intrude on these best-laid plans. While collaborative input from all key stakeholders in the project should be welcome at the solution development stage, it is recommended that subsequent modifications be addressed after delivery of the original specs. Timely execution of an intricately detailed and approved project plan should never be jeopardized by ongoing revisions, making perfection the enemy of progress. If a proposed project that was once unanimously received as a good idea is now subjected to paralysis by analysis, successful execution means resisting the urge to veer off course. Considering an example project such as the creation of a custom web form, the process works best as follows:
Identify and schedule a meeting with all key players
A the one directly responsible for the work itself, the development engineers should indeed be involved in the dialogue with client management from the onset of the project request. As they have first-hand expertise regarding the technical feasibility of the request and the touchstone for all things related to integration with the IT Service Management platform, they should remain the primary liaison between the conceivable and the achievable. Certainly, another notable player who is accountable from the service desk outsourcing vendor’s team is the Project Manager.
Discuss project objectives
Once identifying the remaining individuals who have a vested interest in how the project is defined and delivered, the dialogue is prompted by the pertinent questions. What data fields and drop down options should be included? For new service requests, what are the designated workflows? In other words, depending on each field or drop down selection, to which groups or individuals are the form submissions routed? Are attachments and comments enabled, are there cost estimates, what are the approval hierarchies through completion. How and where are temporary rejections redirected if not outright canceled? Will there be additional look and feel customization and client branding within the form submission portal? What sort of prompts, status updates, and other notifications should be automated, what are the triggers, and who are the recipients?
Define scope, list deliverables, and obtain written approval of the finalized project plan
Once all input has been gathered, vetted, and desired outcomes established, project scope is then thoroughly documented by the solution architect with considerable input from the development team. Leaving no room for interpretation each task should be listed and mirror the proposed workflow diagram including all conceivable “if and then” scenarios within the service request process. Forms should enable data capture of every cause and effect, tracing the request through various stages such as “under review,” “pending approval,” and “in progress” as well as other potential status changes (canceled, complete, awaiting order, etc.). Assuming all client expectations are defined and best practices documented, it’s time to get written approval. Whether it’s the client’s CIO, COO, or Director of IT, the authorized individual next signs off on the project and notifies the service desk team’s Project Manager.
Deliver within project timelines
This is where the developmental rubber meets the road. Upon approval the clock is ticking on meeting deadlines which means, in order to keep all moving parts synchronized, there is little room to divert from the plan once it’s set in motion. The Project Manager keeps client IT management abreast of progress related to timelines and deliverables, but the technical best practices should remain in the hands of the development team including their managers.
Evaluate results and adjust if necessary
Once the customized service request form has been completed, it serves as a baseline for future tweaking either, in the short term, to address a design oversight or, in the long term, as client needs evolve. Assessing the ROI of the project starts with analyzing all of the newly defined data that is incorporated in the reporting package and determining if workflow efficiency has improved. From there, new individuals, departments, approval tiers, and data fields can always be added to the original form structure.
Since there is a codependent link between subsequent steps in the workflow process and prior form entries or selections, revising those first steps after the development team has completed the form can often negate the relevance of what follows. Much like building a house, architects generally don’t make drastic revisions to the foundation in the blueprints after the upper level is finished. ABS DBA Brian Nunziato takes the metaphor even further. “Imagine the predicament being compounded by multiple architects revising the floor plan after the cement had been poured. In the context of project management, this is essentially what happens when various committee members continue to reevaluate a project plan that had just been finalized and approved.” So to avoid a perpetual state of flux, it’s up to the Project Manager to oversee and ensure the execution of tasks and deliverables in conjunction with the development engineers charged with its technical minutiae. Especially if the alternative is retaining a manual process, implementing an automated service request project becomes a sooner rather than later proposition. When end users benefit from the efficiency improvements that immediately ensue, progress just can’t wait.