Give a problem statement to two programmers of similar skills
and there may not be a complete overlap of their solution. With so many books on programming, one may
think programming will be an exact science, but programmers will claim that
it is an art.
Project management is not any different. The accidental project manager may have come
to the profession either due to their excellence in their chosen field or just
landed up due to networking connections. Regardless of how they entered the
field, they will have to understand the core set of skills. Project Management Book of Knowledge goes into a lot of techniques, such as activity sequencing, contract types, change control, etc. One must understand that these are guidelines and operating framework. Tools such as Microsoft Project and Microsoft SharePoint have addressed a number of these requirements in their software to do resource leveling, critical path analysis, multi-project dependency, document sharing, team collaboration, etc.
The market conditions are changing. As adaptive approaches become more popular with teams committing to work done and breaking the stories (deliverables) themselves into tasks (activities), are project managers required to compute critical path or incorporate task level dependencies? If we continue to do these things ourselves, how much are we enabling the teams to self-organize and take decisions themselves? From an organization standpoint, how are we able to tell the bigger picture of how we are allocating capacity and where we are seeing risks? In other words, where is the single source of truth? Newer tools are emerging, and we need to be able to demonstrate our willingness to unlearn our tool affections and relearn what our customers need and the industries demand!
So the tools don't build credibility for project managers. Think of a project manager that updated the tasks in the Project Plan but failed to provide unambiguous direction to the team or failed to elevate to the management the increasing scope of a client? Will tools address these issues? How are the risks factored into how we prioritized our work in the WBS?
So the tools don't build credibility for project managers. Think of a project manager that updated the tasks in the Project Plan but failed to provide unambiguous direction to the team or failed to elevate to the management the increasing scope of a client? Will tools address these issues? How are the risks factored into how we prioritized our work in the WBS?
Just like
knowing SQL Enterprise Manager doesn’t make one write excellent stored
procedures or queries or Visual Studio/Eclipse does not make one write flawless
code, basic understanding of MS Project or SharePoint alone will not make an
effective project manager. Expertise in these tools is a necessary requirement
for a project manager but not sufficient for leading successful project outcomes.
2 comments:
These tools are designed to make project management processes more efficient, improve accuracy of computations, and provide needed organization. While extremely helpful, these tools are nothing more than glorified calculators and are only as useful as the project manager utilizing them. The project manager needs to have a solid understanding of the critical concepts of project management and, as you made reference to above, the soft skills necessary to successfully communicate with their team before they begin using tools such as Microsoft Project. It really doesn't matter how nice the Gantt Chart looks if the data was input wrong and the project manager doesn't have the skills to manage it.
Hi Chris, very nicely summarized. I couldn't agree more with you. The tools are exactly that but the project manager should possess adequate knowledge to deftly evaluate the outcome of these tools and be able to take appropriate corrective action.
Post a Comment