The Real Things Slow Down My Workflow (Shared by the Experts)(Part 2)
The experience shared below was based on the real cases of the experts in project management. Going through the stories brings you valuable insights and if this helped, giving a clap or leaving a feedback represents a praise for the contributors 😄.
Interviewer’s question:
Tell us the tricky thing which used to make your project slow down, and the actions you made to overcome those situations?
Amr Kassem:
About the interviewee: Amr is a professional IT project manager, who started out as a developer (ITWorx INC.), moving on the Business Analysis area (in SunLife Financial and Underwriters Laborities), and finally working in the Project Management area of the industry.
I’ve had to learn this the hard way, unfortunately, but those are always the best lessons, aren’t they?
The simple answer to this question is… Change.
Here’s what I mean:
When managing a project, as a Project Manager, your project needs to be managed at 2 ends, not just one.
The obvious end that everyone knows is the team, your team, the ones spending countless hours to execute your brilliant plan to get to the end goal that you’ve successfully convinced everyone that it’s achievable.
At this stage, most project managers would focus on their team and manage them to that goal, and that is it.
The problem is, businesses are a dynamic environment, situations that dictated the project’s scope a few months ago are prone to change. And now, your project needs to adapt.
This is the not-so-obvious end of the project that needs major focus from you, as the Project Manager.. the business end.
Typically, in situations like this, the business team will start introducing change to the scope (also known as scope creep) and the project team, the heroes that they are, decide to start adjusting in order to cope with the new requirements.
Since moving the launch date is not an option, the working hours start getting longer, then when everyone is already working 12–14 hour days, weekends start to become a luxury.
At first, it’s only 1 day in a weekend, and everyone starts stressing a little, but the project is still ok, things are still on track, relatively.
Soon, as the changes continue to flood in, the project becomes that one that will leave it’s mark on every member of the team.
The ONE project, that no one forgets.
The ‘Project from Hell’.
This is why projects need to be managed not only on the team side, but also on the front end. From the business side.
Most of the time, as the Project Manager, if you can control scope and keep your team isolated from disruptions happening on the business side, your project will go smoothly.
Once changes start coming in, they need to be assessed by the team first-and-foremost, before being added to the scope.
More importantly, all project stakeholders need to understand that this is a change. Even if it’s a small one, it still needs to be highlighted.
Otherwise, you’d be surprised at the number of ‘small tweaks’ you will have to do as part of the project.
Control scope, communicate, and protect your team from external changes.
You don’t have to decline every change. You just need to make sure that everyone understands that it’s a ‘Change’.
So, when you come back to everyone with the reasons to move your launch date, you have a convincing list.
Matthew McCabe
About the interviewee: Matthew is a Technical Program Manager and Entrepreneur with over 18 years of experience in a number of technical fields as well as founding and growing businesses. He is currently CEO of Ultimatum Inc, a platform that allows customers to take action on social and political issues using event based donations to non-profits. (Visit Matthew LinkedIn here).
My practice
A couple of years ago we had an implementation project for a large bank. Customer requirements were clear, and SOW was signed by both parties.
We knew from experience any change in the project scope during execution would mean the entire project plan had to be reviewed.
Scope changes also lead to budget, schedule and quality reviews.This means more time and resources would be needed as against the initial baseline.
Not to mention project costs would be more. We were very clear on this point with customer. They agreed not to make any changes on already signed SOW.
We started development according to our plan. Developers I had in my team had the skills to complete assigned tasks.
As the project progressed, we realized it would not be like other projects. Customer had legacy systems which were making integration difficult. Their systems were so old that we were having compatibility issues.
And at times customer had unplanned maintenance work on their systems.
This was putting our development on hold.
Even though we tried to downgrade some of our modules their systems were just not capable of handling newer technologies.
We realized their systems were not ready for integration. However, they were responsive to our requests to make changes on their systems.
They were cooperative and making changes as we requested but time was not on our side.
At this point project stakeholders were aware of the situation. Most importantly main sponsor knew it was too late to cancel the project. And the management decided to continue despite all the problems.
What I learned
This project thought us we had to :
- Do better analysis of dependencies and risks on customer side.
- Planning everything on our end.
- Assuming integration would be smooth was poor judgement.
In the end, we were able to complete the project with some delay.
Our teams dedicated work made this project success, even it was screw up at the beginning.
Share your thoughts and questions for the managers in the comment section below. Contact us if you want to contribute your own experience to everybody in this community.
Sharing is learning. “The happiest people are those who are contributing to the society” — Ted Turner.
