Key Lessons and Challenges for New I.T. Project Manager – Part II
In the previous article, we have discussed about how “analytics” do with Requirements Analysis and Scope Definition. We have seen how to perform analysis and how it can be applied to various projects. We will further look into the Scope Definition in continuation to our first article.
The technically minded, analytic project manager may understand the importance of getting a clear, precise definition of the scope, but may underestimate all the nuances and subtleties of doing this. If we are quite analytic and technically minded, we may assume everyone else is like-minded and has the same understanding of the key terms! We may not realize that other stakeholders have a quite different understanding of what we are talking about and that we need to probe, rephrase and ask questions to ensure there really is a common understanding. Also, we need to understand there are often legal or contractual technicalities at issue. If we assume these are just “contractual details” that another department will handle, then we are making a dangerous assumption.
In the version four of the PMBOK Guide®, key tools of the “Collect Requirements” process include efforts to get technical teams together with their customers and engage in conversations to iteratively define the scope, and progressively elaborate the requirements. VOC or “Voice of the Customer” and JAD “Joint Application Design” are both used precisely for this purpose. (These are part of the tool of “Facilitated Workshops.”)
In both cases, the idea is to get the engineers, or systems analysts, out of their cubicles and white-ivory towers, and meet with the customers, and follow them around and see what they do in their everyday job, – perhaps, even try doing the customer’s job for a day, or half a day – and truly understand what the customer needs.
Also, the project manager must take great care to ensure that all stakeholders who are affected by the project (and who can influence the project) have been identified. Their political influence and interest must be mapped out. As a technical person myself, when first starting out in project management, I remember disdaining the work involved in understanding “all the company politics,” and only later learned the real necessity of doing this. If we miss a key stakeholder, they are going to show up sometime in the middle of the project, and say something like, “You forgot about me!” You missed my absolutely essential requirements!” This will of course lead to the dreaded Scope Creep, and concomitant schedule delays, cost overruns, and new project manager!
For external projects, we also need to understand the politics and organization of the customer’s company. Thus, understanding the circumstances properly, project managers can successfully gain the project management professional certification.
In the nutshell, we have looked at a couple of the natural tendencies of I.T. project managers, and seen that they do not naturally match up well with skill sets needed in requirements analysis and scope definition. So, if we recognize these limitations, we can take steps to take corrective actions, and improve on our skill sets in these areas. In our next article, we will also look at communication skill sets needed for a project manager and discuss about Communications Management. Again, as you might guess, the natural tendencies of the analytic, I.T. project manager, probably do not match up perfectly with the skill sets most often cited as fundamental for these areas. Stay tuned!
Processing your request, Please wait....
