The Project Doctor Is In: The Importance Of Routine Project Health Checks

By Matt Flores, X by 2

Can a software project be alive? This is an interesting idea, as a software project has no body, no apparent vital signs to measure, and has no other tangible qualities one would attribute to “life." A project is born, it grows, it consumes resources, and has a finite end usually marked by retiring support or through abrupt termination. Inorganic, incorporeal, but it is indeed living, and it requires proper and routine check-ups to keep the project headed toward success. As a doctor performs a health check on patients, so to must project leaders check-up on their living projects.

How would one know when a check-up is required, and how would one perform such a task? It’s never a bad time to assess the facts, but there are no thermometers, EKGs, or other instruments available to chart, measure or diagnose issues. Regular check-ups on critical areas of project configuration, focus, and procedures require more qualitative measurements rather than quantitative analysis. There are several key indicators to ascertain whether or not a project is still healthy, or if some urgent care is needed.

Customer Focus

One of the first pieces a health check should reassess is end-customer satisfaction with project progress. An IT project is nothing without a sponsor, and a dissatisfied customer can foreshadow a project’s premature end. To evaluate how well a project is focused on a customer’s needs, start with a few probing questions: Is there an active business sponsor and are the assigned business resources actively engaged? Are there specific and measurable milestones the team is reaching toward business goals? Are the appropriate business resources being asked to make decisions, or is the IT team making those decisions in isolation? A negative answer to any of these questions is the first sign of a project in trouble.

Project Scope

A poorly documented and unarticulated project scope is a precursor of an unhealthy project. Without documents describing the scope and reach of the project, there is a constant challenge to communicate development activity, milestones, and a projected delivery within and outside of the team. Agile methodology recommends working software over comprehensive documentation, but it does not call to abandon documents outright. Without certain artifacts like a project roadmap or a scope document, the team cannot prioritize or accurately estimate. Accountability for delivery becomes cloudy, and deadlines become meaningless. Create and continually review documents and plans with business, IT and stakeholders, outlining what will be done and when. The goal is to make sure that everybody is working from the same blueprint to deliver the project successfully.

Team Dynamics

Evaluating and resolving issues among the team can be among the hardest problems to solve. Sometimes personnel issues don’t noticeably manifest themselves. Symptoms of poor team dynamics – including poor or insufficient communication, a lack of trust or avoiding accountability – can develop both within the project team and between the project team and the business sponsors. Without trust among teammates, commitment to goals, and clear accountability for delivery, a team cannot function properly and will produce poor results. A key question to ask is: Does the team have a strong foundation and connection with each other to succeed?

Alternatively, the configuration of the teams may itself hinder effective communication. Are teams working in silos? Does information pass from one end to the other between teams of analysts, management and other parties? Does each team member understand why they are working on the tasks they are given? Individuals working in isolation will never reach a common goal. A cross-functional team representing all facets of the project (analysts, developers, testers and others) creates a more efficient, collaborative and successful team.

Process And Execution

Assessing the mechanics of project delivery is more straightforward, but it still hinges on the people involved. In evaluating a project ask the question: Does the success of the project depend on the strength of the team or the strength of the processes? Hopefully, the answer is obvious. Processes are critical, but the best processes in the world cannot compensate for the deficiencies of the people executing them. People on the team will make dozens of decisions daily, and it is their judgment and performance that will affect the project the most. After all, the people on the project team may be the ones who created the project’s governing processes, and if that foundation is flawed, nothing that’s built on top of it will be sustainable.

Still, solid processes must be implemented. Consider a few questions concerning technical oversight and quality control among the developers: Are there regular design and code reviews bringing transparency to the development process? How does a testing team create, validate and review the results of meaningful test cases to approve developed software? How are technical teams reviewing the results with their end-customer?

More broadly, are there assurances that processes are consistent within the team? Smaller teams have an easier time keeping processes uniform. As a team grows, are these processes kept standard, or are there large variances in execution between sub-teams? If there are, how are the teams learning from each other?

Architecture

So far, the health check has examined the people and processes of a project. Technology is an equally vital aspect of reviewing. To identify issues at the right level of detail, and to produce the most insightful overview of a system's technical health, a comprehensive illustration of the system-level architecture is imperative. That is while reviewing code may give us information about a particular page, function or process in the application, a line-by-line assessment of code cannot give a complete depiction of the complexities, sources, outputs and features of a system. Has an architect been keeping proper documentation about the major modules and their interactions? Is this vision shared with the team and evaluated among peers?

Ask this simple question: Is the architecture being followed? Allowing deviations from an established and agreed upon architecture, or continuing to develop while lacking technical oversight, will eventually create a system which trends toward entropy. A crucial part of a project health check is reviewing if there is a known, intuitive and logical architecture, and ensuring the technical team is implementing it correctly.

As patients, people visit doctors when they are ill, but preventative medicine and regular check-ups are still one of the most effective ways to reduce the chance of illness. It’s precisely the same for projects. It's critically important to know what may be ailing a project before the symptoms emerge. Failing to do so can adversely affect the vital signs of any project. However, performing a health check with these recommended approaches and questions will help avert disaster by identifying areas of improvement in time to do something about them rather than when it’s too late. After all, a healthy and well-executed project is still the best medicine for business technology success.

About The Author

Matt Flores is a Software Architect at X by 2. Over the past 10 years, he has played key roles in architecture, software development and project management on several major systems implementations in the insurance industry.  Flores has a particular experiential focus on the long-term implications of short-term technology planning in organizations, and the impact such an approach has on software and application functionality and sustainability.  He holds a BS in Computer Science and Astrophysics from the University of Michigan. 

About X by 2

Founded in 1998 and with offices in the US and Canada, X by 2 is a technology consultancy focused on the practice of application and data architecture in the insurance industry. Whether Property and Casualty, Life, or Health, X by 2’s Architects and Program Leaders understand the insurance business and have proven experience planning and delivering core insurance systems, strategic business applications, and enterprise integrations. For more info, please visit xby2.com.