Fred approaches my office with heavy steps and a question that often makes me cringe. I have done the whole motivating; playing the father; explaining; mentoring part with Fred a thousand times before and yet the question remains - 'when is my project ending so that I can be placed on a new project'.
The answer makes a slow entry into my mind as I contemplate on if I should be breaking the bad news to Fred yet --- "Never. Hopefully." --- I hear a voice deep down in my mind respond to that question.
If you go by the paradigm - everything you do is a project - I am not so sure I agree to Fred or for that matter Tom Mochal's idea of completing a project as quickly as you can. Tom; in his story about how he put a never ending project to end; sounds very typical of how most project managers or developers think about and react to long running projects. He documents his very own personal experience:
“Terry,” I began. “What’s going on? Your project is lasting much longer than anticipated, yet I don’t see or hear any indication that you are behind schedule.”
“There have been a number of scope changes that have required us to push the end date out,” Terry said. “However, you will be glad to know that I am invoking scope-change management. Each change is being approved by our sponsor, so we have been getting extra funding and extensions on our deadline.”
“That explains why no one is complaining,” I noted. “What types of change requests are you receiving?”
“They are mostly for additional features and functions, and small changes to our current deliverables,” she said. “That’s one reason why we have been able to accommodate most of them successfully. They don’t require a lot of work from our team.”
“What’s the future look like?” I asked. “Are you going to be able to complete the project in four weeks?”
“It’s not clear,” she replied a bit apprehensively. “Most of the shop floor supervisors have never had extensive Web experience. Now that they are getting more familiar with that environment, they are finding more and more features they want to incorporate.”
“Well, that’s not entirely good,” I said. “Projects are temporary endeavors to produce a set of deliverables. They need to come to an end at some point. I’m afraid you may be in a position where your project goes on and on, with minor changes bringing incremental and marginal business value.”
Terry agreed. “In fact, I think the team is starting to lose focus and energy. I have some concerns that we're getting a little sloppy.”
“Let’s talk with your sponsor about bringing the project to a close,” I suggested. “This doesn’t mean they have no chance for additional changes. If there is business value in additional modifications, let’s consider them enhancements for the future.”
What Tom fundamentally misses out on; is that successful projects; often never really end. Sprints end. Versions do; too. But not the projects themselves. Any programmer worth his salt who has worked on a product that has stood the test of time and has survived for more than a couple of versions will tell you this.
Linux. Windows. JBoss. Microsoft Office. Go ahead. Pick any successful piece of software out there and ask their parent organizations when they plan on putting a stop to it.
You think that is a stupid idea?
Thought so.
Seriously; that is the whole point of writing code that you can support for years; growing your code organically and keeping it clean for years as you morph slowly over to new technology stacks and churn out new versions that do more; work faster and get better; year after year.
As developers and even as managers; we have this yearning desire to 'start fresh' every once in a while.
A desire to end your project and jump over to another one; often indicates a project badly implemented project in the first place.
The next time you get on a project; dear reader; may I suggest that you work under the basic assumption that your project is not going to end anytime soon and that you are going to be supporting what you write for multiple years to come.
That thought process; dear reader; might be your only chance against the temptation of creating a mess and then jumping over to something else; while someone else does a clean up of the mess you created.
Remember; as you write your code; work under the assumption that you are going to be stuck with your current project for life. Is your code maintainable? Easy to migrate part-by-part when new versions of the underlying technology stacks show up? If your code extendable? Is your code going to not just stay alive but thrive for the years to come?
If yes; you are going to love working in a never-ending project. If not; you might want to start by assuming that you are not leaving the project anytime soon; settle down; and start doing something about the mess that you just created.
I wish you good luck.
Comments are closed.