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.