Is this an individual with a superset of project management hard skills in scheduling, risk management, etc? (Then why not say that? Project Scheduler or Project Risk Manager)

Could it be an individual with domain experience, like software development, construction, IT, etc?  (Isn’t this already the case for virtually all project managers; project management is a skill set and knowledge base that overlies some technical profession, like engineering?)

Maybe they are seeking an individual whose primary role would be the technical domain lead (like, a software engineer), with limited project management knowledge? (Then why not call a spade by its name? Software Engineer Lead )

Possibly they don’t want to pay a premium for a competent project manager; someone competent in people skills, business operations, etc. But do they want an entry level project manager? Or are they seeking one person to do two jobs, at the pay of one?

Is it possible they differentiate between a business-focused and a technology-focused project manager?  (Ignoring the business aspects of the project in favor of the technology has a history of developing technologically great products that are business disasters.)

Laying out several job postings, each by a different company, side-by-side is of no help in finding consistency for the job title.  Although those that do use it use it on most of their project management postings; everything is a Technical Project Management position.  This leads one to ponder the project management maturity level of the organization, especially if their focus is extensively on domain expertise.

However, as I’m writing this post two things have come to my attention.  First, I was reading a blog string when I came across a post by Paul Tiffany, “…Technical Project Manager. This is an HR and IT line manager’s contrivance usually based on false assumptions regarding what constitutes an effective project manager. A good PM is not going to succeed because of intimate knowledge of Agile, but how to manage time, resources and scope to bring in a project on time and within budget.”  — That sounds reasonable, Paul.

Second, I was scanning the AMA Seminars catalog which regularly arrives on my doorstep and I couldn’t believe it, there on page 116, was a course being offered on Technical Project Management. Could this contain the answer I’m seeking?  One of the items that they promise to cover during the course is the “Definition of a technical project management environment”.  Isn’t this a catch-22?  I don’t know if I need to take the course until after I take the course.  All is not totally lost, they do offer a little guidance, it’s related to “R&D, construction, capacity expansion, instrumentation and control, plant outages and more”, the course does promise to cover the project life cycles of construction and pharmaceutical industries, and finally it is noted that this course is not for IT professionals (they are directed to take the IT Project Management course). The bulk of course material covers the run-of-the-mill PM 101 basic hard skills.  Well that makes things about as clear as the weather in Seattle.

Whatever … they all have me confused, and I’ve worked in the profession for decades.  The problem is the expression is not consistently applied, thus adding “technical” to the title does not clarify and only muddles the intended purpose.  Certainly it is not clear and concise communications.  The term “Project Manager” by its self is even better than “Technical Project Manager” because it leads the reader to the assumption the primary role is to manage the project. You know, the person in charge, not the one doing the work. Whereas, I am assuming that a Technical Project Manager is one that manages one or more technical aspects of the project.  You know, the person that ensures the work is technically correct and complete.

My humble suggestions are, if the intent is to clarify the position in the title:

How about being domain specific, like Software Development PM, Construction PM, Hardware Development PM, Agile PM?

How about including specializations, like COBOL Business Application Migration PM?

How about calling a spade by its name, like Lead Engineer/PM, Software Programmer/PM, Project Scheduler?

As a grizzled project manager with a very broad experience base across industries, companies and functional domains within each, what I’ve concluded by all of this is, Technical Project Management job opportunities are not for me because they are not looking for real project leadership. If there is one point out of this discussion I’d like to leave the reader with, it is best summed up in a quote from Harold Kerzner’s Project Management: A Systems Approach to Planning, Scheduling, and Controlling:

“You give me an individual who has good communications skills and interpersonal skills, and I’ll give that individual a job.  I can teach the people the technology and give them technical experts to assist them in decision making.  But I cannot teach somebody to work with people.”

After all that is what project managers do: Work with people across many disciplines to ensure the project meets the business goals (aka, get the job done).

Setting: High school science class quiz

Question: You are given a barometer and need to measure the height of a multi-story building.  Explain in detail how you plan to use the barometer in making the measurement.

Creative Student: There are at least three alternatives:

1. Measure the length of the barometer, and then move back from the building holding the instrument vertically at arm’s length until achieving visual alignment with both (1) the top of the building and the top of the barometer and (2) bottom of the barometer with the same height on the building, as my eye is above the ground.  Measure the distance from my eye to both the barometer and the building.  Finally, use geometric ratio of the two right triangles and the height between the barometer bottom and the ground to calculate the building height.
2. Take the barometer to the top of the building and measure the amount of time it takes to crash into the pavement below upon pushing it off the edge.  Knowing the time and acceleration (gravity) calculate the distance
3. Find the superintendent of the building and offer him this shinny new barometer, if he will tell you the height of the building

Results: Student fails the quiz because his answer didn’t match the lesson the teacher was trying to convey: Measure the barometric pressure at ground-level and top of the building, then using the difference calculate the height.

The story has a few perspectives worth pondering, because clearly both the teacher and the student came away unsatisfied with the quiz results:

• Certainly the student provided three valid solutions and I surmise that he knew the teacher’s answer because quizzes usually reflect material recently taught in class.  Was failing the student a just action on the part of the teacher?  After all, he did meet the intended objective, in addition to showing creativity both scientifically and otherwise.
• Speaking of the objective, which teacher stated as, determine the height of the building, without any criteria for the solution.
  • All four methods can be used to determine this and each produces a different accuracy.  Was accuracy a criterion for the desired results?
  • Another issue is the fate of the barometer, itself.  Was it expendable?  If not, that would eliminate two of the four methods.
  • What if we rephrase the test question to: Explain in detail how you plan to use the primary function of the barometer in making the measurement. Wouldn’t this wording change have added a criterion and narrowed the focus to the teacher’s desired results.
  • I believe the original intent of this story was to illustrate a lesson about the penalty of thinking outside the box.  Yet, isn’t that what we leaders want; someone who solves problems by thinking about them in a new way?

As project leaders, how many times have we been too sloppy in delegating work only to end up with results we didn’t expect?  I know I have. Whether the root is our rushed framing of the situation, poor articulation of our expectations, our cognitive biases creating unstated assumptions, or flawed analogies from past experiences, it was our failure to focus on and communicate our expectations relative to the results.   (Also, see my previous posts: Is the Enemy Us or Fate)

Whether with an individual or the team, next time you delegate work, inside or outside a project:

• Define the goals/objectives, clearly
• Share the all the detail data with those involved
• Articulate your expectations (acceptable/unacceptable), especially the criteria for results
• Discuss the process for getting there; don’t overly constrain how they do it

They may surprise you and provide something better than you expected.

I realize that most of us will never face the challenges confronted by Gene Kranz, NASA Flight Director, on Apollo 13, but the mental exercise is worth doing.  If you haven’t seen the movie, or have seen it and view it as entrainment at the time, I suggest renting it and putting yourself in Gene’s shoes while watching.  You can put yourself through an endless stream of questions:

• Would I have Gene’s mental toughness?
• Would I be prepared to ratchet-up my leadership skills and rally the troops?
• Do I have the knowledge in problem solving and decision making necessary?
• How can I improve my day-to-day leadership, now I’ve seen one of the best project leaders in action?
• Etc., etc. ….

Remember it is a journey of a thousand steps and it starts with just one.

For the rare situation where the project plan comes to an abrupt, premature end or dead stop, it is your time to show everyone what real leadership is.  At this point the whole team, and more, are looking for someone to rally them and provide direction on how to proceed.  Let’s not confuse direction with providing detail instructions on what to do (micro-management).  What’s needed is leadership and a process for the path forward – everybody following and moving in the same direction. It is the followers that will be doing the work and it is you ensuring the process needed to accomplish it is established and communicated, including when and how decisions are made along the way.  Here is a general outline of the flow:

Step 1: Bring the team to a common agreement on the points of the situation:

• The facts
• The assumptions
• The selection criteria for solution alternatives

Step 2: Organize the team’s creativity effort for solution development

Step 3: Monitor the development process and make adjustments

Step 4: Converge to a set of solution alternatives

Step 5: Make the decision and act on it

I’m sure at this point there is at least one doubting Thomas among the readers.  When asked whether creating an Apollo 13 disaster recovery process on the fly and managing to it was a waste of time, Gene Kranz indicated the opposite was the case, it saved time because it gave the team the needed focus.

I wish you the best of luck, if you’re ever experience a bump in the night,  in pulling another iron out of the fire and getting your project back on track; may you have the same success as Gene Kranz.

The majority of unexpected situations that hit a project during its execution are dips in the road to closure; a leader can certainly prepare both themselves and a process for the team, to deal with these.

As the project leader you own the solution/decision process, like any of the other project processes, and are responsible for:

• Understanding the organization’s  decision culture and its implications for affecting a final solution
• Ensuring the process is viewed as fair, legitimate and transparent by the participants, in order to maintain an engaged and cohesive team, through commitment and shared understanding
• Driving the team to converge on a final solution; not personally creating the final solution and selling it to them
• Sharing with the team what the process is and the role they will play and what your role will be
• Fostering a creative environment for solution development

The bottom line is: People want to be engaged and to have their positions heard on any given issue; then, they want a choice to be made, so the team can move on.

The question on the table is, will we have the right person(s) solving the problem and/or making the decision, when needed?

The volume of problems/decisions seen by a project is probably somewhat pyramid in shape, with the bulk lying with individual SMEs and, hopefully, precious few with the organization’s senior management team.  From another perspective, an inverse relationship exists between the problem volume and the number of people and/or organizational levels involved. Involvement appropriate for the situation makes for an effective use of resources within the organization.

So, who is the traffic cop?  You are; the project manager (leader).  How do you know what is right? There are two key issues that need to be considered:

• The composition of participants – Who needs to be involved because it either affects their area of responsibility and/or makes use of their expertise?
• The environmental context of the situation – What are the implications of the situations final resolution, relative to the project outcome, the well-being of the organization, etc.?

My assumption in the previous post was you had a strong, cohesive execution team already in place, which implies the team uses the project meetings to openly discuss challenges (and waste little time on success status) and readily shares information.  As the leader, your role is understand how each challenge/situation is being handled from a process perspective; not necessarily technical content.  In terms of the process, it need to be a hub-to-spoke communications, with you as the hub.  Unlike the solution/decision communications model, which should be point-to-point among the active participants. This is not to imply you can’t be a participant in the technical discussions, it just means in order to lead your focus has to be first and foremost the process.

It boils down to active listening.  Is this person talking to me about project process or technical content? Even if they are talking about the technical content, is there some implied process issues?  Remember, getting the project technically correct don’t necessarily bring it on time, under budget and aligned with the organization’s strategy.

As project managers we have become proficient in transforming the project charter (in whatever form we get it) into a project plan (hopefully, including some risk management) and then charging through plan execution to closure.  But, what happens when thing go bump in the night during execution?  Have you prepared for a discontinuity? I’m talking about the metaphorical equivalent of the plan dropping off the edge of the earthquake damaged bridge. More specifically, something like Apollo 13, an onboard explosion that instantly trashed the entire project’s plan and requiring some heavy-duty problem solving and decision making to create a new plan in short order (if the astronauts are to make it back alive).  NASA didn’t have this scenario in their risk management plan, much less having a mitigation plan.  Yes, I know this is an extreme example and most of us don’t work on projects where people’s lives hanging in the balance, however, some of us have managed projects were the organization’s future is at risk.  It is only when we are prepared for the worst, or at least something worse then you will ever see, does everything else seem easy.

Now that I have your attention by setting the extreme boundary of the topic, let’s take a look at our project teams and think about a few thing that may be taken for granted or just not considered, at the outset.  Things that may help us shine, even in everyday situations, because we are mentally prepared.

Project Management 101, with the PMI PMBOK® as its underpinning; have taught us the methodology for putting together a good project plan, executing that plan and bringing in a successful project.  No problem, with a good plan and team of SMEs (subject matter experts) we can sleep at night.  Right?  Sometimes.

Even with a solid project plan created through your competent leadership and active participation of an outstanding team of SMEs, have you ever stopped to think about all the problems that get solved and all the decisions that get made in the course of executing the plan, most of which were never considered or documented as part of the planning process, even if you did risk management?  Some are at the day-to-day level of individual SMEs, while others may require the involvement of senior executive management, and all points in between.  What will the effect of any one of them be on the overall project effort and outcome?  Some are constraint changing, other plan stopping, and many go unnoticed.

In the posts that follow we will consider three items the PM should be concerned with:

• Are the problems/decisions being addressed by people with the right level of responsibility and/or expertise?
• Does the project team have a process for problem solving and decision making to handle the daily dips in the road?
• Are you and the execution team ready for a bump in the night?

Needless to say, this discussion is situational, dependent upon the size of the project, its complexity and it criticality.  On the higher end of the scale, like the Apollo 13, it is more important to formalize a process for problem solving and decision making.  However, even on the lower-end of the project spectrum, there are always benefits for the PM to have at least thought through some possible scenarios.

The former approach is works fine for simpler and straight forward projects, but for large complex projects it can be very limiting because it will result in missed opportunities, ignored risks, overlooked interrelationships, discounted non-linearity, dismissed discontinuities.  On the other hand, the latter approach of keeping a holistic perspective, allows us to remain open to all aspects of the situation while working toward a solution; integrative thinking.

Integrative thinking is an art form.  It embraces complexity and its causal relationships; has a high tolerance for change, openness, flexibility, and disequilibrium; welcomes surprises and disconfirming data.  It involves an iterative, heuristic process, expanding the number of salient variables, exploring their causal relationships, examining the problem in a sequential fashion while maintaining a overall perspective of all variables and their causal relationships, developing an integrative solution.

Some skills of an integrative thinker:

• Search for non-obvious factors and causes of problems – connecting the dots
• Don’t assume linear cause-effect relationship – look for non-linearity and discontinuities
• See problems as a whole while examining the parts – organization and complex projects are systems with integrated parts
• Create whole new options by recombining existing options or synthesizing new options – avoid  either/or choices of options
• Asking the right questions – Seeking out discordant and enigmatic information and individuals

Are you still with me?  Good.

How does this all fit into the business of project management?  Well for one, it is the differences between what I will call “the competent project manager” and a novice.  In the days gone by, we called them senior PMs; the grizzled veteran, decades of experience, proficient leader, intuitive, gifted problem solver, accomplished decision maker.  (Inflation appears to have hit Silicon Valley.  I’ve seen job opportunities for senior PMs requiring a minimum of 5-years experience.)  The competent PM understands we live and work in a complex world full of ambiguities and has developed the skills to not only deal with it but to excel, like integrative thinking.

A linear view of the business of corporate projects; the strategy is cemented by the executive council, the programs/projects are chartered, the PMs are engaged, the projects are (eventually) completed successfully.  In reality however, the business process is ambiguous; the strategy is not cemented because of the constantly changing business environment, the internal politics of the rank and file cause an ebb and flow of projects within the portfolio, the over allocation of resources cause discontinuities between the plans and the work. In other words, the situation most project management professionals are constantly complaining about and the environment they are expected to execute within.

Let’s take a step outside of project management and the corporate world to view a continuum extreme.  As I’m writing this, the US government, specifically the President and his advisors, have been hunkered down on the issue of how to move forward in Afghanistan.  The much publicized military solution (backed by some Senators) is to throw more troops at the situation; a very linear approach.  However, all indications are the President has established a decision process that is taking an integrative approach by addressing a more comprehensive set issues related to stabilizing the region, as a whole.  Talk about a situation built for integrative thinking, this certainly qualifies.  Think about the competing opinions on his advisor team, dealing with other nation states both within and outside the region, dealing religious interest, dealing with specific individuals, dealing with US priorities.  It makes most projects within the corporate environment look easy. How complex was your last project compared to what the President is attempting?  Talk about ambiguities, non-linearities, discontinuities, interrelationships, risks and opportunities, discordant and enigmatic information, this effort has all of them in spades.

I realize I’m leaving you without a, say, 5-step how-to solution; however as I stated, integrative thinking is an art form involving a heuristic process — and this is a blog.

Ambiguous situations are usually characterized by conflicting signals, signals intertwined with background noise, disconnection between actions and events, and suspension of expected cause-effect relationship.  We are in the reaches of complexity, non-linearity, and/or discontinuities; our cognitive biases don’t fit, the situation doesn’t align with any of our mental frames, we can’t recall past analogies.  What is one to do?

The phrase that comes to mind is, “think outside the box”.  Isn’t that where we are with an ambiguous situation; outside our box?  I’ve always been fond of saying that I don’t have a box.  The reality is that some of us just have bigger boxes than others, mostly because of more life experiences, education or we are natural integrative thinkers.

For the ambiguous situation, you have to think (noodle it out).  I know I’m asking a lot, from some.  First, check your biases. Is one of them causing the ambiguity, if so, why? Does it need to be reset?  Second, check your mental frames?  Are the two frameworks out of alignment because your underlying assumptions need to be adjusted?  Third, is the lack of analogies a lack of experience or are you attempting to apply old experience models to a novel situation?  Finally, if you are up against a roadblock, call for outside help.  This can be a more senior person or someone from the outside who can provide a fresh view.

The ultimate solution is to become an Integrative Thinker.  Integrative thinking is an art form.  It embraces complexity and its causal relationships; has a high tolerance for change, openness, flexibility, and disequilibrium; welcomes surprises and disconfirming data.  It involves an iterative, heuristic process, expanding the number of salient variables, exploring their causal relationships, examining the problem in a sequential fashion while maintaining an overall perspective of all variables and their causal relationships, developing an integrative solution.

To reason by analogy; recognize a past experience is similar to the current situation, evaluate what did and didn’t work in the past situation, make a choice about what to do and definitely not do.  Certainly analogical reasoning differentiates the novice from the grizzled veteran PM, based on the sheer number of stored past experiences.

For example, if you are defining the scope of a computer server development project and have worked on similar projects, experience will tell you that the printed circuit (PC) boards will require multiple prototypes (“turns”) before a workable version is obtained.  Your experience is PC boards always have required multiple iterations, thus multiple turns should be scheduled.  On the other hand, your hardware developers may be telling you they expect to nail it on the first round.  Do you believe them or your experience?  They are telling you one and you’ve never see less than four.  This is where the analysis comes to play.

Use of analogies can be especially powerful when applied in an area unrelated to the past experience.  Many times this results in innovation. One technique to foster innovation is having team members with varied backgrounds, thus avoiding groupthink, but this is a team item which we will leave to another time.

A few words of caution are needed in use of analogies.  We tend to focus on similarities and downplay differences.  Sometimes we are reluctant to surface and validate the underlying assumption of the two situations.  We have to be wary of having a solution in search of a problem.

Up to this point we have discussed analogies as a positive contributor to the situation; a way to move forward.  What happens when our experience fails to provide an analogy?  The chances are you have encountered a novel situation where the pattern recognition doesn’t square with past experiences.