What is the main driver of test and measurements project failure?
The test and measurement industry certainly has evolved significantly in these over seventeen years or so that I have been involved in it. The typical challenges back a couple of decades were heavily associated with the toolset available to the typical Test Engineer. LabVIEW, by National Instruments, though was making good progress towards becoming a more complete development environment, was still trying to establish itself as the de facto T&M leader in Software tools. Other more mature languages such as Visual Basic and C++, though very widely adopted by the Software Engineering community, weren’t really tailored for test and measurements. On top of that, the off the shelf available set of instruments were still very limited. “Technical challenges” was the answer of choice back in those days.
As NI LabVIEW and TestStand became market leaders in the test and measurements industry a few years later, their level of completeness became proportional to the increased number of adopters. Those two environments started to allow more and more, along with the advances made in the off the shelf instrumentation, Engineers and Scientists to materialize their thought out solution to the most various problems. The Software really started to become the instrument, allowing more difficult problems to be solved with the technology. The instrumentation flexibility certainly followed that improvement.
This brought about the second wave of standard answer to the question that motivated this blog; overall system complexity. This indeed is a serious issue as, nowadays, the expectation for a test system is that it will thoroughly test the most technology advanced unit under tests; from missiles, to pacemakers, through cell phones and microwave radios. The test systems of today are true engineering marvels when compared with their counterparts of the past. As such, the number of technical disciplines that members of a test and measurements project team need to master has overcame by miles the domain knowledge of the Test Engineers of years ago. This is indeed a real challenge for modern test and measurements systems. However, this has become more and more a known issue, and organizations involved in building test systems have been equipping themselves with an army of engineers from multiple backgrounds. This indeed brings the answer to the complexity problem. Instead of having a couple of MacGyver know-it-all Engineers that are virtually impossible to find, hire and keep to begin with, who can, at best dabble at the most intricate engineering problems that don’t fall within their main areas of expertise, organizations are now in favor of having several Engineers focused on their respective areas of training.
This is a great improvement. However, it drives the next standard answer to the question; project management. Project management is probably one of the most catch all answers to the “why do T&M projects fail?” question. Granted, the test and measurements community is still crawling in the adoption of professional project management to direct project execution. They are still somewhat stuck in the past years when it was enough to have a good Engineer functioning as the Project Manager, even though that Engineer really didn’t have the training, experience, knowledge, or, in most cases, even the desire to become a Project Manager. As test systems became larger and larger in size, the corresponding projects to manage their execution follow that trend. Larger projects are obviously more difficult to manage than smaller ones; therefore, most people feel justified in answering this question with the typical; bad project management is what drives T&M projects to failure.
Though I certainly agree with this general answer, I have certainly seen my share of failed T&M projects that were actually managed very well by professional Project Managers. If bad project management is the driver of T&M project failure and we see well managed projects fail, then…
This is where we get to my answer to the question. What I believe to be the root cause for T&M project failure, obviously, assuming that good project management was applied in its execution, is a human issue, not a technical or project management issue specifically. Granted, lack of well established requirements and poor project planning are certainly the two main drivers of project failure, and they indeed qualify as bad project management. However, what I advocate is that the actual drivers of these two conditions are two: poor communication with stakeholders and missing stakeholders. T&M projects these days, besides the aforementioned complexity that drives the creation of large technical project teams, are a pivotal component of any organization. Whether they are being built for quality assurance at the end of the production line or in support of a NPI (New Product Introduction), the truth of the matter is that, if the test system fails, a snow ball effect is started that brings serious consequences to the organization. As such, the typical group of project stakeholders, or, the people who are somehow touched by the T&M project is vast. Not only that, but they come with different backgrounds as they work on different departments within the organization.
Under this circumstance, the typical technical Project Manager, either won’t be technical enough to lead the project team, or it will be too technical and have personality shortcomings in connecting with the pool of stakeholders. www.tsxperts.com has some white papers that elaborate on this more. For this post, I will leave you with the idea that, what started as a technical problem and migrated into a project management problem has now turned into a human problem as the main driver for test and measurements project failure.