The IT Project-Tracking Database: Keep Your Key People in the Loop

Information Technology is a project-centric industry. Every task is either performed as a part of a project or constitutes rollup toward creating a new project. No individual, organization, department or company can escape the rigor of discipline and perseverance that project management enforces as prerequisites for success. However, information Technology often receives a bad rap for the relatively small number of successful initiatives as a percent of the total initiatives launched, compared with other departments.

Technologists are viewed as inherently more disciplined — and more capable of thinking and planning in a structured manner — than their “non-technical” counterparts.I believe this classification is unjust. No matter how trained the human mind, it still cannot replace the uber-productivity tools that assist project discipline today. Initiatives fail mid-stream or fail to take off not because they are not good initiatives, but because of the improper amalgamation of the prowess of the human mind with the appropriate technology (read tools) that it has created for its assistance.

This piece is not about educating the reader on project management or the productivity tools available today, but rather about a simple set of mechanisms to employ in order to yield a higher success rate in the completion of IT initiatives and projects.

The Power of Your Intranet

Several IT departments do a shoddy job of educating their customers and users on their efforts and initiatives. The term “hard at work” cannot be underestimated, especially when there is a general feeling in the user community that IT never really gets anything done.

The federal government recently announced the use of a website that will allow people to track the progress of federal IT projects. IT departments should (if they are not doing so already) use the power of their intranet websites to publish such a roster of initiatives and projects.

This platform need not be fancy and should not become another long, drawn-out effort itself (talk about a catch-22 situation!) but rather something that can be quickly deployed on an existing portal using existing collaboration technologies such as SharePoint or Documentum. Such a tracking database can then be published via company communication channels.

This type of listing accomplishes two main goals: First, it provides greater transparency to the IT department. The entire company can now examine what its IT department is up to and what kind of direct and indirect benefit its users can avail themselves of in the coming days and months. Second, and more importantly, it acts a platform for IT to market the importance of certain programs and initiatives — especially ones that do not have complete buy-in from management or different departments.

Examples of such initiatives include cloud services and virtual desktop infrastructure — initiatives that impact almost every department and individual in the company, and that force employees to get their jobs done in a different and sometimes radical way.

Project managers, sponsors and IT executives should make this project-tracking database a part of their daily “to-do” routine. They should incent their direct reports to use this as a platform for communicating the progress of their work to the rest of the IT and customer community.

This tracking database should not just be a nominal entity that exists for the sake of existence; rather, it should contain some key attributes that every person in the company can draw important conclusions from — and use them to form the basis of key decisions that impact not just the project itself, but also the overall vision and direction of the company.

Tracking-Database Attributes

• Project classification: The tracking database can seek not only to list all projects, but also to classify them so they can be sorted, filtered or searched using keywords. Projects can be classified into various buckets such as departments, technology, and active vs. future, source and type of funding, the phase of the project, its schedule, and estimated time of completion. This classification can be further enhanced by allowing users to create their own portfolio of projects that they are either involved in, have a stakeholder or project sponsor relationship with, or simply have an interest in.
• What the project is about and what it seeks to accomplish: This provides the reader with a summary of the project objectives and the reason for its existence. Moreover, this should be the “elevator pitch” for the project, whatever it may be: cost savings, user experience improvement, or some tangible benefit to the organization. This is very important for projects that are pilot projects, technology assessments, proof of concept or do not have complete buy-in from management.

  Many times, stating the obvious in simple business terms is enough to provide that “last mile” justification for the existence of the project and helps overcome some of the roadblocks. Cost is one such variable. Most roadblocks have to do with the amount of money invested vs. the benefit in dollar terms. One caution is to ensure that this pitch is factual and stated in simple language to allow anyone to interpret what is being said. Technical jargon should generally be kept to a minimum and used only if absolutely necessary.
• A project dashboard: a summary of the project activities, status, schedule and direction. This is to allow IT managers and stakeholders visibility into where projects of their interest stand. A project dashboard should be a summary view of the project and should leave out mundane details that may not interest the reader looking to spend no more than five minutes looking at the health of the project.

  This page can and should be visually appealing with colors and charts indicating the progress of the project. For example, green, yellow and red can be used to describe the project’s schedule or health. Pie and line charts can be used to indicate financials or other quantitative data, and a flowchart can indicate schedule.

• Financials: If project financials are published on a periodic basis, these should be made available as well. Some departments may choose to password-protect this information or make it available only to certain audiences as necessary. The important point here is to make all information available in the interest of transparency, but to be judicious about what audience it is made available to. Typical data that should be published include the project budget, the funding sources, incurred and projected expenses, and any anticipated overruns.
• The project plan and schedule: The health of any project is generally gauged on the project plan and tracking of the project relative to the plan. Publishing the project plan along with the project schedule allows audiences to ascertain whether the project will be completed on time (this information will be available via the project dashboard, anyway) — and if not, the reasons for the delay.

  If the impact to the schedule is due to resource issues or dependencies, and if the reader is in a position to change those circumstances, this information can be crucial for follow-up. The project team can use this information as a communication medium — especially in cases where the project is large and involves many different groups.

• Interaction: The use of wiki or any Web 2.0 technologies can make a tracking database interactive. Project members can be allowed to blog about their experiences on the project, and end-users can be allowed to post comments, questions and suggestions.

  This can be a great forum to allow a large group to interact with the project team in a moderated fashion. It also keeps a two-way communication channel open and eliminates the perception that work on the project is being performed in a vacuum.

  This is very important when the outcome of the project depends a lot on the user experience — with desktop deployment or upgrades, for example. Users can be allowed to subscribe to updates via email or RSS feeds so they feel connected to the project team in a virtual sense.

• Risk and issue-tracking: Nothing, in reality, is hunky-dory — and projects are not without issues. So it is only logical that the project information page have a section on risk or issue-tracking. This allows project team members to track and manage roadblocks that are especially prevalent in this economic climate (e.g., cost, security issues, smaller staffs).

  This need not be a rant section, but rather a forum to show audiences the efforts made by the team in navigating through such issues and coming up with creative solutions and alternatives wherever possible. Obviously, if a project hits an insurmountable roadblock, this could very well be the place where everyone gets to read about it. If the project is near and dear to them, audiences should be allowed to propose suggestions too!

• Integration with productivity tools: Technologies today allow project-tracking databases to interact with end-user productivity tools such as Outlook to create calendar entries, reminders, task lists — and even send out automatic email reminders.
• Integration with project documentation: The project-tracking portal can and should be linked to the project documentation repository when applicable. It can be made accessible on an as-needed basis, but the availability of such a facility allows the audience (with the proper privileges) to view or access such documents for their perusal.

I am not suggesting that creating such a project-tracking portal will solve all issues plaguing IT today, but it will certainly go a long way toward easing the tension between IT and its project sponsors and end-users.

If the federal government can do it, companies certainly can!