It seems like every article I read about project management assumes that project management is all about managing technical projects. The real world is filled with projects that have nothing to do with computers and somebody manages those projects. Why do all project management forums seem to be strictly technology based?
Projects I have managed professionally are business projects in the areas of construction, international business, new opportunity, process improvement. Technology is only one aspect of the project. The technical leads are not the project managers. I don't see Gantthead addressing much more than the technical either.
Why? Saving Changes...
Sort By:
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Dear Anonymous, you raise an excellent point and I quite agree with you. More and more, organizations are seeking to establish project management as an enterprise best practice and strategic skill set. While this aim is supported and even led by organizations like the Project Management Institute (PMI), forums like Gantthead.com, and the vendor community, often times project management is discussed in the context of IT projects. I would tend to believe that this is more on account of the fact that those involved in the discussion are typically from the technical field rather than anyone having a view that project management is only about technology projects. Many of the Gantthead articles and submissions from the department heads like Mark Mullaly, PMO; and Michael Wood, Process Improvement; and others, are simply excellent, very insightful, and deal with business issues outside of and beyond just IT. My experience has been that Gantthead addresses whatever is topical, interesting, and, of course, posted...! I would be interested in your experiences and advice. For your non-technical projects, what approach did you take with respect to project management processes, tools, and collaboration. For example, do you manage your non-technical projects following any particular process or approach? What kinds of tools do you use for planning, scheduling, communication, and resource management? And how do you go about collaborating with your team and the stakeholders? And most informative would be, how do the executives that you work with, relative to non-technical projects, view project management in general? A penny for your thoughts...! Cheers. -- Mark Perry, VP of Customer Care, BOT International Saving Changes...
Anonymous
Much of what I've read about technical projects, the project manager is expected to be the expert, thus more of a supervisor. Such is not the case in the real world. You cannot be the expert in everything. You must listen to your experts and draw out of them their expertise for the project.
The biggest challenge has been lack of management in my contract companies. Often this is not discovered until too late. If you can not get someone else, in those circumstances, you are required to step in and manage for them in order to complete your project.
Use the methods and tools in the PMBOK. The same methods and tools are are used to manage non-technical projects. You adjust your method of communication to meet your team's and sponsor's needs. Saving Changes...
You wrote:"..., thus more of a supervisor. Such is not the case in the real world."
I find this statement very demeaning and an extreme over simplification.
As you know project management is a complex solution to a complex problem. As Peter Senge points out, complexity is increased by the time distance between stimulus and response. IT product development and service projects represent good examples in studying and working with this complexity. They are ripe for better management because quality issues and other project issues can go through several phases of a project without a significant product issue. Also, computer engineering and specifically programming is an engineering discipline where more engineers are needed than our schools can produce. This means, often there is a lack of mentorship and education for the junior staff. Further putting the complexity of the problem on the project managers. This is why many IT project managers are also experts in the technologies. Those project managers who try to manage large technology projects find their lack of knowledge doesn't let them identify and address the issues that their project suffers from.
I would suggest you revisit the wealth of information presented by IT PMs. Instead of viewing IT project managers as “supervisors” view them as PMs who have a significantly different problem set than yourself. I know I’ve learned a lot from non-technical PMs.
Saving Changes...
Mary Elizabeth DiabDirector| Leadership FormationTallassee, Al, United States
Quite an interesting discussion. In my experience, part of the reason that the most talked about area for Project Management is technology is because it has the most need. It is glaringly obvious when Software projects, in particular, are poorly managed. However, I also find that the limited availability of highly qualified technical PMs has led to gifted technicians poorly managing projects. In my experience, a great PM is a great PM in ANY industry. While the technical details and "snow" meter will need to be developed, it is often easier to take a great PM and move him/her into technology than take a gifted technician and move them into the PM role.
Gifted technicians often become bogged down in the weeds and lose sight of the overall project. In addition, if a deadline is approaching or a resource is lost, many technician PMs will jump right in and start coding. As a result, the overall view of the project may be lost.
One lesson that the IT community could certainly learn from the general PM community (where it all started BTW) is that one of the keys to good Project management is a team where each lead knows their business. If your technical person is new, they shouldn't be the lead... I wouldn't want the PM who was managing the build of my house to put a guy who is inexperienced as the carpentry lead. So, good observation and I agree it can be a challenge. Saving Changes...
Anonymous
Good observation Mary!
To David's comments:
This is an excellent discussion. So to continue.... if you have a project manager whose lack of technical knowledge doesn't let them identify and address the issues that their project suffers from then that project manager is not doing due diligence in risk management. Likewise the technical lead is falling down on the job for failing to raise these concerns.
There seems to be some confusion as to the role of a project manager vs. technical lead. I understand that many technical project managers, assume a multiple roles. During the initial planning phases, all the roles should be clearly defined. All staff are responsible for advising of potential risks. The project manager should understand if they are performing multiple roles and address the potential time constraints as a risk as well.
This is probably why, there is so much concern over technical project management. The sponsor is trying to shortcut or save money by having one person perform dual roles. Thus the project is resource contrained and things like "risk planning" are omitted. It is very clear that on medium and large size projects, the project manager has to give up the technical role and just manage in order for the project to be successful.
Saving Changes...
Anonymous
This discussion thread is rather timely for me. My organization is currently engaged in a tug of war between the PMO and software development in that, the software development group is arguing that we either a) do not need project managers as they are not technical enough to add value to our projects or b) need to change their job description to remove ownership of anything related to the scope, budget or schedule. The reason for this is that in our organizational model the Development Manager controls the resources, whereas Project Managers do not directly manage any resources, therefore arguing that by not having control of the resources it is impossible to give the PM accountability for the scope, budget and schedule.
Part of the difficulty is that we are trying to form job descriptions/division of responsibility to fit a structure that itself doesn't necessarily make sense. Our structure is one that is ideal in a product development organization, however, we are strictly a custom development shop, in that we do not engage in projects for which the client does not define the scope.
Any insight or support that anyone could provide that argues in favour of the need for the project manager would be greatly appreciated. Saving Changes...
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Dear Anonymous, I might be missing some of the context, but it seems that your organization is focusing on reporting structure rather than process. If you can get your organization to place more focus on process, then many if not most of your internal arguments will cease to exist. Project managers rarely own anything such as resources, scope, schedule. That is a non-issue. And in terms of best managing a client development project to deliver upon agreed to scope, schedule, and cost - this is core project management and a skill unto itself - no matter who in the organization does it. I suspect that there are many organizational and political issues surrounding the various arguments and points of view that are being discussed. It might not be what your management wants to focus on, but try to introduce the notion of defining and improving your processes. Again, I might be missing much of the context, but Good luck! -- Mark Perry, VP of Customer Care, BOT International Saving Changes...
Mary Elizabeth DiabDirector| Leadership FormationTallassee, Al, United States
I'm going to go with Mark on this one. It sounds like there is too little focus on process. In fact, knowing of your company only from your description, I would suggest that the software development group is putting up a smokescreen of sorts. I have found this is fairly common in siloed organizations (which most are). Often this is because each silo is concerned about headcount and "owning" resources rather than meeting the company's strategic goals.
The objections expressed relate to the perception of a lack of value. In such a case, the issue of accountability is a non-starter. In reality, as Mark stated, we PMs rarely own resources. However, our accountability for scope, schedule, and budget comes from our ability to place influence in appropriate areas and communicate issues impeding progress (i.e., resources being pulled or budget not being available) to appropriate levels of management. For this reason, PM is 90% about soft skills and interpersonal abilities.
If your company does custom application development, you may find that a more projectized structure makes sense. It makes reporting lines blur somewhat, but allows for better focus on the customer's deliverable. Many of the large consulting companies (I worked for IBM in a past life) function in this type of way. People come together for the project, then go back to their organization when it ends. I would be happy to describe further if you have interest. Saving Changes...
arlene trimbleAssistant IT Director| Local GovernmentAlamo, Ca, United States
Project Management is definitely not limited to technical projects. I have used it also in process improvement, organizational maturity model participation, contracts development, and others.
For the PMO and PM processes to be recognized in your organization, there needs to be governance in place. Saving Changes...
