After my first year of being a Business Analyst I decided that the role of a Project Manager was useless. My boss, a Project Manager, would always ask the developers the same question; “When do you think this will be completed?” The response was always the same. The developers would start off with, “It depends…”, “maybe…”, or “approximately…” In the middle they would sprinkle in a bit of “but if this goes wrong…”, “if there is a conflict…”, or “if something else comes up…” Finally they would end the conversation with, “so, I’m really not sure when this can be done.”
Software development can surprise you like a weed sprouting up in your garden; before you know it, it is out of control! Knowing this, how and why would anyone ever want to set a hard timeline? The cycle starts when a developer is forced to choose a date or, worse yet, the Project Manager picks a random date. That date then becomes set in stone via meetings and documentation. For weeks everything seems to be on schedule until the final release meeting. At this point the developer says “well, I ran into this issue, and this issue, plus that issue which caused another issue to come up…” Everyone in the room except the developer is completely baffled that the deliverable is not ready.
The fun doesn’t end there… After the room overcomes its initial shock at the developer’s statement, the cycle finally completes. The developer gets blamed for not making a deadline that was never promised in the first place. The development manager gets blamed for not pushing the developer to meet the deadline. The Project Manager gets blamed for not monitoring the project closely enough. The company is blamed for not delivering the project on time. And I, as the Business Analyst, watch this whole cycle repeat over and over again. It drives me nuts!
I began thinking about where the problem first started. Was it with the Project Manager promising a date that was never guaranteed? How was the Project Manager unable to estimate a good timeline? Aha! It is because the Project Manager does not have a development background! How could he possibly understand how development works if he has never developed before? My immediate thought is that all Project Managers without a development background should be fired. Then I realized that my goal of becoming a Project Manager would be crushed because I did not have a development background. What to do?
I moved on to a company that did things differently. This company used Scrums and Sprints as their project management tools. I must admit, it was love at first site. The daily calls provided instant notice to the project team if the project was or was not on track. It also let everyone know if the timeline would change. How nice was this? The Project Managers at this organization were much more on top of things, and since everyone was in the know, the vicious cycle of broken timelines did not exist. The Scrum/Sprint system was the first time I had seen project management actually work.
As someone without a development background, I found it easy to follow what the developers were doing. With the constant feedback from the project team, it was easier to put more resources on the project right away if needed. It was simple to push timelines if we needed to. It also helped alleviate issues that normally would have taken longer because they were brought up and taken care of right away.
It is mind boggling to me that more companies are not using daily Scrums as a tool to manage projects. Not only do they keep everyone in the loop at all times, they also seem to eliminate many other useless meetings. This gives everyone, especially developers, the ability to focus and work. Timelines are met and no one is disappointed. It’s a win-win situation.
