Project Management Central

Please login or join to subscribe to this thread
Differences in Technical and Project Management Viewpoints
Network:528



One reason some technical people view project management as needless bureaucracy is that technical and project management errors are vastly different. In most cases a technical error can be quickly fixed with just a few keystrokes. However, any mistake a PM makes (such as not identifying a stakeholder) will often have dire consequences for the project. For example, failing to include a single stakeholder’s requirements might lead to the creation of an unusable product and the waste of many years and millions of dollars.
This difference in the impact of technical and project management errors requires PMs to rigorously focus on process and detail, whereas technologists generally don’t worry about errors because they can easily fix any that occur. Explaining this to your technical teams might go a long way to getting them to comply with project management processes.

Thoughts?
Sort By:
Page: 1 2 next>
Network:210



Having come into Project Management from a Technical group, I have to disagree with you. The best technologists are highly detail oriented and have little patience for what they consider sloppiness. The reason you may see a reluctance to follow process is that there is a disconnect between the PM processes and the processes used to develop or implement the systems. That you used the statement "a technical error can be quickly fixed with just a few keystrokes" also demonstrates a lack of knowledge of the inter-dependencies in most IT systems. If, for example, a database server is not given enough RAM, the database will not perform as intended, and the apps and Web services dependent upon that database will suffer. This is analogous to the unknown stakeholder you mentioned. Identifying and correcting this issue is certainly much more than making a few keystrokes.

In my opinion, a PM on a highly technical project should have at least a basic understanding of the technologies being implemented, and be able to understand and identify how the PM processes can integrate processes and communicate effectively to ensure that the project requirements are understood. A lack of clear technical requirements is a major cause of project failure, and a pattern of not providing clear requirements in a timely manner will cause technical teams to look at Project Management as needless bureaucracy.
...
1 reply by Eric Simms
Nov 29, 2018 10:44 AM
Eric Simms
...
I should have specified that I was describing a coding error, which might be caused by the omission of a single character and once identified can be quickly fixed.
I agree that PMs with no clue whatsoever about the technical project they're managing, and those who impose non-beneficial processes upon technologists will cause them to view project management as pointless.
Network:528



Nov 29, 2018 9:42 AM
Replying to Glenn Chundrlek
...
Having come into Project Management from a Technical group, I have to disagree with you. The best technologists are highly detail oriented and have little patience for what they consider sloppiness. The reason you may see a reluctance to follow process is that there is a disconnect between the PM processes and the processes used to develop or implement the systems. That you used the statement "a technical error can be quickly fixed with just a few keystrokes" also demonstrates a lack of knowledge of the inter-dependencies in most IT systems. If, for example, a database server is not given enough RAM, the database will not perform as intended, and the apps and Web services dependent upon that database will suffer. This is analogous to the unknown stakeholder you mentioned. Identifying and correcting this issue is certainly much more than making a few keystrokes.

In my opinion, a PM on a highly technical project should have at least a basic understanding of the technologies being implemented, and be able to understand and identify how the PM processes can integrate processes and communicate effectively to ensure that the project requirements are understood. A lack of clear technical requirements is a major cause of project failure, and a pattern of not providing clear requirements in a timely manner will cause technical teams to look at Project Management as needless bureaucracy.
I should have specified that I was describing a coding error, which might be caused by the omission of a single character and once identified can be quickly fixed.
I agree that PMs with no clue whatsoever about the technical project they're managing, and those who impose non-beneficial processes upon technologists will cause them to view project management as pointless.
Network:54



As a sr. engineer with a project management role, I often see it as a difference in the perspective of the technical specialist vs. the project manager. The specialist teams often look at the PM as an administrative status taker role. Many times I've heard, "We could be more efficient if we didn't have to answer to project managers." Often they try to hide what they're doing (progress, problems, changes, etc.) thinking it will be easier to tell us when they're done instead of working together along the way.

This often creates a problem because they are focused on their piece only, and not how it fits into the larger perspective. They forget the downstream value chain. They don't realize that other technology teams are running plans in parallel that disagree due to undisclosed changes and major rework will be required by multiple teams when undisclosed changes or problems are discovered late in the game.

The PM by contrast is focused more on integration than on technical details. They need to look across the detail level plans of the individual teams to make sure everybody is working to the same plan, and when the plan falls off track, who all is impacted. A technically savvy PM that wants to jump in and help jr. engineer the technical solutions for teams often has to take a step back and remind themselves (if others aren't already reminding them) that their job is to help enable everyone to get their jobs done, not to do the jobs for them.
Network:14727



That's what SME's and BA's are for, to help bridge the gap between domain-specific knowledge and the processes and deliverables required by the project manager.
Network:39



Interesting post Eric. I think the comments from Glenn, Keith and Sante all touch on points that need to be considered by the PM.

I think the other factor is time frames (which extends Keith's comment). As a PM my time frames are usually significantly longer than any other group in the delivery team. I have a longer term goal in mind. Whereas others are more task orientated.

One thing I'm trying to improve on is being able to judge how much of the detail of the bigger picture is useful to communicate to the technical teams so they understand broader impacts of their work and and any delays, without decreasing their efficiency with "needless" meetings and requests.
Network:38



Interesting perspective. I believe that you have to have a kick off meeting where everyone's role on the project is explained and the value that they provide to the project and the project dependencies on their work. So they understand the down steam impacts of what the are doing.

As a PM in ICT taking the technical team on the project journey is key to the success of the project.
Network:91



"[...] a technical error can be quickly fixed with just a few keystrokes"

Tell this to the 189 people that were on board of the 610 Lion Air flight that crashed not long time ago. Well you can't tell them anymore but you could tell this to their relatives and friends.

Technical errors usually have a much more negative impact than project management errors this impact many times is deadly.

Think of a car design error that forces the manufacturer to recall hundreds of thousands of cars ti fix. That would cost a lot of money and depending on the design error can also be deadly.
...
1 reply by Keith Novak
Dec 01, 2018 1:46 PM
Keith Novak
...
I think your hyperbole missed the mark on Eric's point.

In those cases, there is a massive amount of oversight to prevent such errors including a very robust process of requirements derivation, validation, and verification involving multiple engineering departments, non-advocate reviews, and regulatory oversight. In fact there is an entire field of engineering devoted to prevent such errors, and they are far beyond the purview of any one project manager.
Network:54



Dec 01, 2018 11:57 AM
Replying to Adrian Carlogea
...
"[...] a technical error can be quickly fixed with just a few keystrokes"

Tell this to the 189 people that were on board of the 610 Lion Air flight that crashed not long time ago. Well you can't tell them anymore but you could tell this to their relatives and friends.

Technical errors usually have a much more negative impact than project management errors this impact many times is deadly.

Think of a car design error that forces the manufacturer to recall hundreds of thousands of cars ti fix. That would cost a lot of money and depending on the design error can also be deadly.
I think your hyperbole missed the mark on Eric's point.

In those cases, there is a massive amount of oversight to prevent such errors including a very robust process of requirements derivation, validation, and verification involving multiple engineering departments, non-advocate reviews, and regulatory oversight. In fact there is an entire field of engineering devoted to prevent such errors, and they are far beyond the purview of any one project manager.
Network:152



Happy to read a dynamic string of opinions. When so many projects alround the globe fail to meet the expectations of the stakeholder, there needs to be a falicitator to play a balance between the technical and business stuff. I feel that the need of a PM came into picture at this point. As PMBOK says the major part to be played by a PM is in integration management
Network:30



I suggest the underlying issue is one of differing definitions of success and I will also suggest there is at least a third voice in the mix, what I will call the Business. Often, Project Managers care about Project Success, Technical People care about Technical Success, and Business People care about Business Success. Unless these definitions are continuously aligned and realigned, the conflicts and distrust evident in the initial post and some of the follow on responses arise. The solution is really to have ongoing conversation to maintain a consolidated view of success.
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

Cyberspace: A consensual hallucination experienced daily by billions of legitimate operators, in every nation

- William Gibson

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events