Five Things Project Managers Wish Everyone Understood
The future is like a dark room, and it is better to enter it with your eyes wide open. Project Management is one way of making sure that your eyes remain open with certainty – if not confidence. This wisdom dawned on me recently. And, while one part of me continued with the documentation efforts, the other took this opportunity to understand the basics of Project Management – yes, from a technical communicator’s perspective.
Based on what I observed, here’s what Project Managers wish we understood:
Scheduling and Estimation
Almost every day, we stumble upon something that takes us longer than expected to fix. That’s a usual thing in IT. More often than not, such delays extends the project deadline. A delay of even a couple of days might delay a project by a month. Developers need to realize that time and cost interlink. That’s why Project Managers expect us to come up with an accurate estimation for our work. Estimate time that’s enough for you to manage your work, including the almost certain last-minute changes and goof-ups. If you’ve delayed completing a task, you might overrun your project deadlines and that would be a costly affair.
A well-thought estimate bridges the gap between uncertainty and certainty.
Meeting and Tracking
Some folks in my team feel that daily stand-up calls or meetings are just waste of time. Considering that most of them work on more than one project at a time, they are right to an extent. But, what they fail to realize is that such meetings help more than just keep a track of the project. Such meetings are the perfect platforms for everyone to flag roadblocks, challenges, impediments, and risks. For new employees, such meetings are where they get their daily tasks from their leads. For experienced professionals, such meetings help track their progress.
Similarly, the timesheet tool isn’t there to stop you from doing what you wish to. If you put in the right number of billable hours, you can concentrate on your work and let the Project Manager worry about total amount of work on the project. That’s what estimates are for.
Walk the same distance every day to cover a long distance over a sprint.
Standardizing and Improving
Projects come and go, systems stay forever: that one line, Project Managers wish we understood. We should follow a certain method of carrying out our daily workplace activities, from a sub-task to an epic and from a problem to its resolution. We must comply with the methods and, if possible, improve them over time. Small steps eventually become stepping stones. Small improvements eventually lead to big improvements.
Co-create value by defining and redefining your work practices.
Implementing Documentation at the Core
There are times when smaller projects can do away with the need for documentation by largely including the line-level changes in delta documentation and email exchanges between consultants and clients. However, that doesn’t negate the requirement for documentation. All changes must eventually confluence into a single repository where we can track their histories. So, documentation continues to remain a major part of Project Management. And, while some of us do not consider it a billable activity, we do need to run it in parallel with the test sprints to remain on schedule.
Let documentation be the mortar that holds the functional bricks in place.
Establishing a Pattern of Learning
This one applies to everyone. It is important that we continue the learning process. With every project, each challenge should look like a rung in the ladder of success for us. And, every such ladder we climb should bring us a step closer to our long-term goal. Of course, saying this is easy. But, what is it that Project Managers wish we understood? That the learning curve is steep towards the beginning and end of a project. And, that’s why assimilating the lessons learned from a project is as important as sharing insights in the beginning.
We must make sure that we formalize and standardize the learning processes; that we share learning lessons vertically (not just from the lead to the engineer but otherwise as well), horizontally (peer reviews), and randomly (across teams and levels); encourage free interaction between and across project colleagues; and ensure everyone (along with their learning experience) is on the same page on closure of a project.
Learn from others’ experiences, and contribute a few of your own, too.
We know two things for sure: that all projects and challenges are exclusive and that changes and deviations happen. The knowledge of the above-mentioned points lends us an additional perspective to look at the same problem (and solution) at hand: the project.
Suyog Ketkar is a certified technical communicator and a published author. In his work time, he is busy conveying correct message correctly. In his non-work time, he is a super-busy father. You can reach him at http://suyogketkar.com.