I'm Jason Firth.
I recently wrapped up a fairly major project, which I spoke of earlier: Implementing a large software package for 2 sites.
The story of this project can be seen as a tale of two cities, or of two different groups with fundamentally different requirements, and importantly fundamentally different ideas of what success looks like.
In one city, we have the 10,000km view. From this viewpoint, the project was a huge success. We successfully designed the project, successfully trained all the users, successfully deployed the software on time and under budget, and our metrics look great -- thousands of work orders created, thousands closed, as large increase in the number of active users of the software, and we can all pat ourselves on the back for a job well done.
In another city, we have the close up view. From this viewpoint, the project was much less successful. The design was clunky and complicated, the training was incomplete and in some cases meaninglesss, the go-live day was a mess which never really got cleaned up, time and budget are irrelevant because of the former, as are metrics. Congratulations on foisting a broken system on a bunch of unwilling users, who are upset that we've taken their original tools away from them!
Let's look at another project.
Implementing a new control system, the spec comes back from engineering. We followed the spec completely, successfully implemented it, documented it, and patted ourselves on the back.
The problem? The specs were for a control system that wasn't going to work. After being implemented, the system was never put into service for any appreciable amount of time, because it didn't correctly control the process.
So, which viewpoint is correct?
Both. It all depends on how you define success. That's why it's important to define success properly to encompass both viewpoints: Both the micro and the macro. Is the project successful as a project, as something with a beginning, middle and end, with a budget and concrete goals? Is it successfull as an ongoing operation afterwards, will it actually be used, is it acceptably free of defects, does it actually do the intended job? Is it structurally good, is there ongoing documentation and training, continuous improvement set up in the systems at the facility you're at?
If you're able to succeed on the micro level, and at the macro level, then you've got something that's going to make you look good over time.
Thanks for reading!