The Importance of Management

OK so kinda scrambling to find a topic and wanted to talk a little bit about the importance of management in general not just PM.

Management as intangible as it is, is crucial to any organization. Clarity of vision, facilitating communication, and focusing work efforts is the role of management in general and in my experience its a rare thing to have clear thinking management in position.

Whether its the pressures to perform or that the majority of management is pulled from the rank and file technicians of an organization who by virtue of their work earned their commission not taking into the account that management skill and expertise are rare skills to be sure.

Some Principles that Have to be there to make it work:

A Vision Shared and Articulated Vision - Management has to get their resources on the same page.

Empower and Be Empowered Command Style - This means you trust the people that are under you to do their jobs and provide them an atmosphere to do so.

Versed in the Art and proficient in the science - You understand people and the situations and can artfully navigate them to a positive outcome and you understand the science of management the generation of performance metrics and the processes to get them.

Hopefully this helps a little on the management aspects of project management

- Optimal Optimus

Software Development is like cooking with too many chefs in the kitchen ;p...

Working with Software Developers is always a challenge IMO (not so humble opinion) its the more difficult challenge as compared to other more tangible Project Management disciplines (IT, Construction, etc). The simple reason is that you are dealing with the intangible and often fluid nature of software.

Software of any significant value is simple in its value offering, but inherently complex in its development. This complexity is an equation of developer personalities, responsibilities, organizational infrastructure, communication levels, political battles, resources all shifting to meet the needs of the consumer of the application that needs to be balanced adroitly. The same could be said for a construction project or server deployment but the concept of ground being broken and servers are on the dock is by and far more real than, how an abstract object will be handled by the as yet un-coded system.

Where in traditional IT shops and more concrete project organizations like construction there are a lot of regulatory strictures that exist, governance is part of the overall development model, in software similar concepts exist but the ways to meet them are as limited only by the architecture and skill of the development team(s) and their product owner(s) framing the problem space. That's why software is so different. So many factors so many people feeding the critical mix soup, then factor in the vendors, the methodologies and the time and associated risks it often is a maelstrom of chaotic decisions and knee jerk reactions all to the beat of the all mighty "Time to Market Drum" hammering away at you.

This is not to say all Software shops are the same they aren't, like anything there are orders of Magnitude of chaos. Software serving high governance industries will never be built the same as a video game (having worked in both sides of the spectrum I can attest to that). But it never looses its fluidity its almost art like quality, that when your cooking it it has to come out right or it will fail to meet expectations. Developers are like Chefs striving to make the experience unique and to their liking, like true artisans of their craft and the restaurateur the product owner or management hammering away at them to make the restaurant shine and then there's the general manager of the restaurant doing his best to keep the kitchen in shape and the chef's from fighting with each other and churning out wonderful dining experiences so that people come back and buy more.

Awfully flowery but close enough.

The whole idea here is that for me at least, a project manager in a software environment is supposed to bring harmony in a world of dissonance. To pull together the team by whatever means (hard selling or soft selling methodolgies, tools, communication models whatever is apropos to the problem space) necessary to bring clarity and concordance to the team and start delivering value add as quickly and as efficiently as possible. (Somewhere in there there has to be management support but that's a whole other story)

Agile Perspectives

I recently attended an Agile Seminar sponsored by RallyDev (a great tool so far as I can tell). Anyways I found it very very informative.

Ordinarily I am never one to drink the proverbial "Kool Aid" but I found their approach to implementing the Agile Methodology as very rational and sound. Yes there was an air of Yoga to it but it was light.

I found the discussions with Israel Gat to be particularly ... profound would be too strong a world but insightful is a much better ring to it. His blog captures alot of what I discussed with him in our break out.

Either way what I took away from the event was that not everyone that does Agile is a "Bible Thumping Zealot" and that the methodology is sound to the point major corporations have leveraged the principles presented in the Agile Manifesto to great success. So for any of those who watch the Dog Whisperer it was an opportunity to see the possibility that it could work, it can be done, and that is very empowering and also encouraging.

It also reminded sadly how far away my current organization is from truly being Agile or even following the precepts of Agile to realize any of the economies of scale that the panelists are extolling and challenging us to meet.

But if everything is an iteration then we are a few more iterations away from having a shiny agile implementation. Here's to the next release.

-Optimal Optimus

Process is a side effect of Communication not the other way around!!!

PROCESS PROCESS PROCESS

The more often than not battle cry of the Project Manager.

PMBOK teaches process and standards...
SCRUM is a process...
SO is XP...
SO is waterfall...

So what's the big deal? That means process is important right? Wrong!!!

Process is a child of communication. In an environment where there is little or no communication or mutual understanding of business objectives process is typically viewed as a liability because there is no context associated to how it will improve the business.

Conversely communication does not happen initially in a process environment it happens as organizations and individuals interact and identify areas for which they can agree upon and identify economies of scale. The interactions and communication ideally are identified and then held as a standard to be met or reproduced creating a "Process".

This is why I always cringe when I hear a PM say the solution is to create a process when the true answer is the PM needs to create a "dialogue" (read here communication) between the business objectives and the teams working on them and identify what is acceptable to both entities. Based off of the outcome of the dialogue then the process can be identified and followed.

PM's should never be in the business of bringing process to an organization but in the business of creating dialogues that allow an organization to build its own processes.

Ya Savvy?

-Optimal Optimus

Respect. Recognize!!!

So I participate on a couple of forums regarding project management and I answered a question regarding respect.

Not very well written but I decided to post it here as being a PM basically means you need to cultivate a lot of respect fast in order to be successful.

I know this breaks the Fighter motif I have has the last couple of posts but. Well things change.

-Optimal Optimus


In my experience it all comes down as to what respect is defined as in the organization or between individuals for that matter.

Because I am the manager you must respect me... (does not cultivate respect)

Because I am talking you must respect me and not talk over me (does not cultivate respect)

Because you work for me (does not cultivate respect)

Respect IMHO comes from mutually seeing each other as equals and communicating as equals without preconceived notions of superiority or influence whether or not they may be there circumstantially.

Everyone here is the same we are trying to provide a solid product with great value proposition (respectable)

Everyone here has opinions and insights we may not all agree but if you have insights and opinions lets make sure they a rationally supported and are in line with our business goals (respectable)

I need you to attend this meeting, based on my understanding of business needs and what the meeting represents it should prove beneficial to our objectives (respectable)

I want us to take this approach because it supports our organization in this manner and is in line with the majority of our organizational operational units.(respectable)

It's a matter of engaging your team, empowering them, respecting them as professionals. Not ordering them about. You don't have to be a manager to have respect, nor should you as a manager abuse the respect your title bestows upon you.

If anything Respect is a commodity that is earned by trust and honesty and openness of intent than anything else and whose value as emotional and sub-context currency is immeasurable.

If you are gonna play... better know the game.

So in keeping with the Project Management meets competitive sport fighting motif, I have decided to tackle the concept of does a project manager need to have technical expertise/industry experience to manage projects effectively.

For me the answer is surprisingly… No. But wait there's a caveat to that answer…. Can a project manager manage a project without intimate technical/industry experience? Yes, but will they be as good as a project manager with the technical/industry experience… No.

But why?

There's the rub. In the fight game there is a saying "Ring Time is Golden".

What the hell does that mean?

It means that fighters that have logged "Ring Time" hours or have fought actual fights possess as strategic advantage to a fighter without.

Well what about all that sparring and training? Wouldn’t that help a fighter without the "Ring Time"?

Yes, they would.

But when it comes down to business and a fighter's business is winning a fight in the ring, in front of a crowd. No amount of sparring or training prepares you for the cheers of the crowd, the pressures of your family, the tunnel vision, and the myriad of psychological challenges that a fighter takes on, on top of the physical combatant. This isn't to say that some fighters sheer physical prowess and skill can compensate for a lack of "Ring Time" but ask any serious fighter out there, the smart money is on the guy with the best "Ring Time".

Being there. Knowing the rules of the ring. Controlling the anxiety, mitigating the affect of personal factors, possessing the clarity and singularity of purpose to fully leverage your training and experience is what makes a great fighter and similarly a great project manager.

I chose the opening for "The Contender: Asia" which centered around Muay Thai in which several rising stars in the professional Muay Thai circles were contestants in competing with very well known names in the Muay Thai champion fighters. And as I expected the more experienced fighters rose to the occasion and the other fighters with less experience, less ring time fell to the affects of the pressures of the ring. Some couldn’t reign in their personalities, some their lives outside the ring, their health, and in the end the last 5 fighters were all veterans of the Muay Thai ring. No accident. Ring Time is golden

Technical and Industry experience equate to having the tools talent and sense of situational awareness that can take a good project manager and makes him one that can in "Jedi" like fashion see the future improving response/reaction times making things seem effortless or even scripted. It is rare sight to see but a beautiful to behold.

So to boil it all down. A Project Manager can manage any project but when the stakes are high and they often are, its always best to go with your "game face on" and in order to have a game face you have to know the game. Knowing the Game means you have been there before and you didn’t choke. You rose to the occasion, faced the challenges with poise and composure and sent them all home packing. It takes a project manager with that situational awareness… that "ting Time" to make it happen. So if you are in the game for blood best have some quality ring time under the belt.

- Optimal Optimus

Project Management… Science or Crusade? Red Pill or Blue?

So this is my first post on R-Cubed Project Management and I thought long and hard about what the first rant would be because that’s really what I am doing here, ranting. I decided to go with a Matrix/Transformers motif ergo the little YouTube snippet with the apropos Red Pill "Truth"/Blue Pill "Blind Faith" dialogue; Project Management Methodologies/Tools/Processes...Science "Red Pill" or Crusade "Blue Pill".

Being a project management professional for the last 10 years I have seen my fair share of project management flavors of the month: Agile, PMBOK, LEAN, XP, Scrum, etc. What gets me standing on a soap box is that these PM Tools, (cause that is what they are tools) come complete with pushy evangelists and "over-internalizing" chest thumping adopters.

Instead of looking at the problem space that an individual organization faces and what tools that the scope of the project management profession has developed i.e.: Agile, Scrum, XP, LEAN, PMBOK. These so-called "practitioners" adhere blindly to a methodology or worse a PM Tool Suite thinking that it will miraculously solve all of their operational woes. Nothing could be further from the truth.

There is no magic bullet or cure to project management or management/leadership in general. The only thing I can think of that would come close to a cure for project management/leadership woes is to look at it scientifically as opposed to taking it on like a crusade.

Selling Agile processes is not project management.

Identifying how applicable and how Agile processes can be implemented and thereby prove a value add is project management. The idea that having multiple iterations and weekly meetings is not being "Agile"; its simply having multiple iterations and weekly meetings. Thinking that any one methodology or any particular part of a "methodology" means you are doing it 100% is dangerous ground to stand on and since being in Project Management means you try to find the least dangerous ground to stand on, it would make sense to pause and re-evaluate such decisions.

Science or "Scientia" in the latin means "to Know" which later spawned the Scientific Method meaning "to know" via the practice of observation and experimentation. This concept has a couple implications on this issue:

• It takes away the marketing pull of Methodologies/Canned Workflow Tools as a panacea for Project Management.
• It applies a reason/rational approach to how we make our management decisions this includes what methodologies/processes/tools we adopt.

Applying a scientific approach divests us of the emotional clamor of "crusades" to handle projects in an "Agile" fashion or a "Lean" process. It allows the Project Manager or decision maker to evaluate the methodologies/tools/processes to make decision on what makes best sense to solve the business problem. After all we are in the business of business not thumping the latest management mantra. Just because an expert says that true blue Agile works best at XYZ company doesn’t mean that true blue Agile will work for yours. It may take a hybridization of different methodologies, tools, and processes to get it just right for the decision maker and their organization.

Crusades, generally speaking have rarely ever been a good idea because a crusade takes rationality out of the equation and replaces it with faith. Effectively saying "who ever believes hard enough will win out in the end". It's rings with the tone of "God Wills it". I don’t presume to know the "Will of God" or to speak for him. I will however take my "God-given" brain and apply rational thought to my selection of methodologies, tools , and processes to solve the business problems presented to me, because it makes sense and not because the "Agile" gods will it.

-Optimal Optimus