Skip to main content

When a Project Dies

Despite our best efforts, sometimes projects just die.

Projects die for different reasons – a new stakeholder comes in with a new vision, the stakeholder cancels the project because he or she realizes what they wanted could be done within current applications – there can be a myriad of different reasons.

This week, a project of mine died. Initially, I wasn’t sure how I felt. This had been a very challenging, long, drawn out project. We met weekly with the stakeholder and her staff almost every week for over a year. I have two over-stuffed manila folders of notes I had taken during meetings.

Let me be clear that we are new to the business analyst world and still working on our overall process, so while that timeline may seem unreasonable, the stakeholder was fine with it. The project was completed once, when the stakeholder and her staff met directly with the developers, who started planning the application in their heads during the first meeting. The final product wasn’t up to par and therefore, was never released to the end customers. The stakeholder wanted it done correctly this time and was willing to wait as long as necessary to achieve that desire.

The stakeholder brought her own challenges to the table. She would often change what their process was while other members of her staff would question the changes. They didn’t understand how to use computers all that well and I suspected a few of the “problems” with the initial application were merely user error.


Advertisement
[widget id=”custom_html-68″]

But, it was my job to complete this project to the best of my abilities and offer them an application they could use.

I created the SIPOC and As-Is and To-Be process maps while user requirements were edited again and again as the meetings went on. During the project, our area decided to switch from the waterfall to the agile methodology to prevent year-long projects with no results. I developed user stories and learned information I hadn’t learned during the year-long meetings.

As a business analyst, I felt finally ready to hand the information over to the technical team. Unfortunately, several personnel changes left us with few developers to work on the project. Ah, the best laid plans of mice and men…

Still, time wasn’t of essence as the stakeholder and one of her staff members were out this summer on extended leave.

Then, last week, I learned the stakeholder’s area has been disbanded after review by a new director and just like that, the project was over with little fanfare.

While part of me was elated – this seemed to be the never-ended project – another part of me was mournful. I had invested quite a bit of time and gone through a huge learning process with this project, only to have it never see the light of day. Part of me wanted to say, “Yes, yes, it is finally done and it is beautiful,” to the naysayers in our area that said the stakeholder wanted too much, was unreasonable, and the project itself was unnecessary.

I had also developed a friendship with the stakeholder and her staff. We’d exchange pleasantries before and after meetings and learned a little about each other. Now, everyone had been laid off and as painful as the project was at times, I wish they hadn’t been.

There are plenty of other projects on the horizon, but I’ll always remember this one as the project that helped me grow and taught me a lot of lessons.

Comments (2)