This is my corner of the blog-o-verse dedicated to all things Project Management.
I have been in Project Management going on 10 years now, from many different industries and unfortunately for you I am going to share unsolicited some of my insights and opinions on the some parts Art other parts Science of Project Management.
And if I sound negative to you... too bad.
I also like Transformers so "Until All are One"
Back when I was in college I loved reading pulpish novels about Spies and Specialized Warfare along with a whole bunch of Fantasy and Science Fiction etc etc. I am a creature that tries to stay as close as I can to my roots.
So back in the late 90's I found Dick Marcinko's Rogue Warrior series and I was hooked. I liked the gritty in your face style. It was most definitely attractive seeing as how much fun it was to read about a guy and his like minded pals, who bucks all the little rules and fights for all the big ones.
Then it got worse... I found his Business Book line and I was in heaven. All the foul language aside it was all just takes on the Art of War and the Go-Rin-No-Sho and all matter of treatise on Strategy and Combat that I had already absorbed at an early age.
Nowadays Rich Marcinko is making a Videogame and I actually know a couple of those folks. But I must say that I am lucky to have gleaned those insights from those tomes of knowledge that have helped inform if not shape my career.
People should check'em out. They are definitely entertaining if not insightful. Nowadays my reading list is a lot more ... tame, but man while definitely not on the Harvard Business Review top 10, did these Rogue Warrior Business series resonate and still continues to do so today.
* Rogue Warrior (1992) (with John Weisman) ISBN 0-671-70390-0 * Leadership Secrets of the Rogue Warrior: A Commando's Guide to Success (1997) (with John Weisman) ISBN 0-671-54514-0 * The Rogue Warriors Strategy for Success (1998) ISBN 0-671-00994-X * The Real Team (1999) (with John Weisman) ISBN 0-671-02465-5
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
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)
So abused a word. There are so many aphorisms that exist stressing its importance, its rarity, etc.
Here's the deal for me. Communication happens all the time. When we talk, email, text, blog, twitter, even when we don't say anything. The problem is that people do not realize that their communication doesn't always make sense to everyone that sees it. I am guilty as anyone in this regard.
I am of the opinion that as project managers we should be the best communicators on the deck. My preferred comm style is to be as unvarnished and concise as possible, this more often than not does not help me win friends, but what it does help me do is illustrate issues that need to be addressed. Format and spacing and whether or not you put a little ":)" in it never come into play.
Why so hard? Doesn't the more bees with honey adage apply? No. Here's the reason why and its an inflamatory statement but that's ok I have a thick skin.
Communication requires some sort of mutual understanding, typically the understanding is centered around a shared vision or goal or something that the one or both participants can agree upon or desire. The more simple and easily articulated the goal the more likely mutually beneficial outcomes come to fruition. Sounds easy right?
Here's the rub. As PM's we are often in the difficult position of trying to establish communication channels, plans, responses etc. We are charged to do this with team members with vastly different experience sets, agendas, and perspectives. What one participant understand can be vastly different than the other. It is imperative that the PM and stakeholders are clear and succinct to identify the mutually agreeable goal. Why do you ask? If there is no discipline and understanding of how difficult communication and collaboration is the team will tear itself apart trying to come to a resolution.
Communication Discipline - adhereing to a code of conduct typically "taught" or "trained" in regard to communicating with others.
If someone was taught that 5000 emails a day was status quo and that was the extent of their discipline then it is exponentially difficult to get those individuals to do something else or communicate with them that there are alternatives to their current level of communication discipline.
Repetition, patience and working on clarifying goals become the only effective means to improving the situation.
In the game/consumer product development world those things are laughable.
Dependencies? Of course there are dependencies probably hundreds am I going to track them all in some sort of master map of a schedule and plan when they change daily as we innovate or find new ways to do things or move in a different direction. That in and of itself would be a full time job. How much value add do I provide saying oh yeah based on dependencies we have lost 4 days of work
Critical Path? When everything has to happen doesn't that mean everything is on the critical path? There's an equation to Critical Path the "sequential tasks with the longest duration" Oh yeah but you throw that into mix with the maze of Dependencies how do you make the critical path worth tracking?
Float? Time you can leverage to move resources and effort to other parts of the project in hopes to get it back on schedule? Is there such thing as spare time in a product development environment. Shouldn't we be working full tilt from inception to launch?
Everything has its place and so do these concepts. The important thing to remember is that the context changes depending on the environment. There are dependencies in Product Development environments as well as float and a critical path. However they are all treated differently and "managed" differently.
In a Product Development organization dependencies are acknowledged and worked through on a tactical level, so that the schedule concentrates on what going to be delivered next, not how the past is affected it. If dependencies are not being met they are raised as an issue(s) and resolved by the appropriate management level.
Critical Path is the entire project, every task, every item. How do you manage it? Issue Management. When things like dependencies put the delivery of the product at risk it immediately becomes the most important item on the critical path. Every item that stops the forward motion of the project is the "Critical Path" and needs scrutiny and resolution.
Float? there is no float, float is an illusion, a luxury of those who do not realize that at any given moment if we don't judiciously apply our efforts and resources we end up slipping. Its the job of every Product Development group to be fully leveraged at all times on delivering the product or game since I happen to be in the game business.
This is a great show. Definitely captures the essence of being a late 20's early 30's in the new millenia. Part of me is sad that I'm actually 3 years older than the main stars in the show. The comedy is sharp and relavent. Cobie Smulders is ridiculously haawwwt. But my favorite character and probably the favorite character of many is the character of Barney Stinson.
In this newest episode Barney doled out an "Awesome" insight in the world of corporate america as evidenced by the youtube clip above.
The episode centers around the gang talking about resumes in hopes of helping Robin's character from being deported due to visa violation. Barney relates what Corporate America is looking for in an employee.
As we watch Barney's ridiculous video resume about randome non relavent buzzwords with flashy images and no mention of anything he has done. The gang points out that resume has nothing about what you do and Barney looks up and says exactly.
"Corporate America doesn't want people that do. Corporate America wants people that look like they do but don't; in fact doing anything ... that will get you fired." (or something to that effect)
A more true statement has never been uttered. I have had my share of hiring and firings and let me tell you from my experience more people are hired on flash than substance and when substance is provided they are usually punished for it.
I get all kinds of excuses for it:
"Nature of the Beast" "Welcome to Corporate America"
Excuses aside doesn't change the fact that its not right. If you stretch it a little all our economic woes stem from the tolernance of this line of thinking.
"Sell a good game and don't deliver. Then protect your sale by doing as little as possible as cheap as possible possible."
Sounds like a winning solution set to me.
I founded Generation-Joe and its professional oriented R-Cubed Project Management (the more professional oriented sister site/blog) to take a stand against sentiments like that.
We should stand on principles
If you can make a difference then make one.
Speak your mind without fear of reprisal
If you are going to speak make sure it makes sense and its not bullshit
SO I have been thinking. Yes I know its not often but I have my moments.
This Web 2.0 business:
* Wikis * Social Networking * Twitter
All of this stuff what's it mean to the practice of project management. I mean the extent of web 2.0 to project management IMO has been the leveraging of Sharepoint. The concept of project work spaces and such is hardly news but what is news is that the communication that Web 2.0 starts bringing and taking it to the mainstream means we as project manager can start driving communication by the tools we use.
Does a client need the strict hierarchies of Sharepoint? Are they fluid and flexible that they like some sort of wiki implementation. Do they leverage an artifact tracking system? Web 2.0 provides fast and easy implementations that allow the PM to concentrate on the communication model rather than implementing a tool. I think its pretty cool.
Many people talk about Situational Awareness but few people understand it.
To me its really like the Matrix concept of "Bullet Time" the ability to move or respond to stimuli far beyond normal ken. Everything moving in "Slow Motion"
How does that apply to project management?
Simple PM's serve as the situational awareness for an organization. We should be able to perceive stimuli and respond faster than humanly thought possible. Our processes should support this dynamic.
Situational Awareness is analogous with Clarity of Vision, that people who have experienced high pressure and intense situations and triumphed have related that it was as if you could see everything and it was all moving in slow motion and it felt right.
Project Management should provide that clarity that awareness that no matter how risky or how chaotic that the right move the most expeditious move is clear and ready to be taken.
That's how important situational awareness is.
I included a little "Matrix Bullet Time" for an example.
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.
So I am now a newly minted Certified SCRUM Master!!!
Do I feel any different? Have the Project Management gods opened up their pearly gates and blessed me with a glimpse of arcana that will revolutionize my organization?
One word? No.
For those of us just joining the blog, I am not big on the seemingly growing trend of Methodology Fundamentalists growing out there and just like their Religious counterparts, they only seem to make things more difficult than they really are.
Just call me a secular bastard but bottom line it there are things that we can do in project management in business that take all these tools these methodologies and apply them judiciously and where appropriate to make significant gains.
Bottomline: Results matter. How we get there whether pure XP, Scrum, Waterfall, Ninja Techniques from the Black Scrolls of Mu; Ship the product with minimal bugs/issues within expectations and everyone busts out the stoagie and we go home with the prom king/queen WOOT!!!
That said am I glad I took the training? Absolutely. It opened up some areas for improvement and experimentation to the hybrid model I have been employing . Will I sport the credential? Damn Skippy!!!
Above is probably one of the best pictures of the Agile Methodology I have seen to date. (I found it in a google search)
Image - 2008 ENVISAGE Technologies Corp. 1441 S. Fenbrook Lane - Bloomington, Indiana - 47401 - 812.330.7101
So here's the second post… the Long Game vs. the Short Game in Project Management. Its been my experience that many organizations suffer from myopia. The reality is that as a professional in Project Management and Management in general the role we must play requires us being able to clearly see "The Road Ahead" for good or ill and travel the road efficiently and effectively.
Its not an easy issue to tackle. Individuals who suffer from "management myopia" typically speaking, lack the ability to discern that it is a problem. When someone brings it up an issue that requires forethought or foresight they dismiss the issue as "nebulous" or "chasing ghosts".So what to do?
I really don’t have much of an answer for this but here it goes…
… I try and explain the problem in analogies.
"The Long Game"… problem here is I don’t play golf so I will put in a MMA terms. The long game is the "strikers" game.You engage with your opponent a distance. You read his movement, look for weaknesses, opportunities to strike your foe for maximum effect all at a distance. The skill sets used rely heavily on seeing everything with little or no contact while remaining maneuverable so as to predict or by your efforts lead your adversary into a situation where you can win the exchange.Mistakes can be costly, catastrophic mistakes lead to an early KO, but small mistakes say misjudging a punch but keeping your guard up allow you to take a little more and may allow you to reposition for a solid counter, because of distance you have a greater margin of error.
"The Short Game"or "Grapplers"is similar in that it’s a struggle/contest in MMA, but fundamentally different.Instead of reading at a distance you are intimately entwined with your opponent. The reading is done in subtle shifts in weight as the both of you jockey for position and in the brief instances between knees, fists, and elbows fly at your noggin. There is little time to try and predict movement and the stakes are higher when you try to apply your energy to win the engagement. In the "Short Game" the margins are smaller and against a skilled opponent its one mistake and that’s game. In less than it takes to blink your eyes you find yourself in a short arm bar or a triangle choke and all the pain, torture, and agony you faced as you trained and prepared for this fight get flushed down the tubes and all that is left is to go home broken and defeated and possibly crying.
That sounds awfully grim right? It is. Getting in the ring is grim business and when you’re the project manageror a manager in charge of projects that will play a heavy party in your organizations financial well being, well that’s grim business too.
SO does that mean I should focus on my "Long Game" and ignore my "Short Game", does one have more value than the other?
The answer is simple no. You need both.
Ifyour "Long Game" is good you can defeat your opponents from afar without them touching you, but typically you face adversaries who are more than up to the challenge. The idea here is you wouldn’t have taken the risk to fight if the guy was a complete tomato can the purse/rewards wouldn't be worth the time.
So that means you have to leverage your "Long Game" to pound on your opponent softening him up so that if and when it comes down to the "Short Game" you can defeat him readily as you increase your margins in the aggregate and improve your probability for victory.
In business speak it means you move "strategically" (Long Game) and get buy in, solve the big problems, position yourself for maximum effectiveness ahead of time. Eventually you are faced with the "tactical" (Short Game) realities of your operational problem space, here because you set up the problem with your "strategy" you have more options "tactically" to finish and reap the rewards of success.
BTW the clip is from UFC 77 Anderson Silvaa Muay Thai/BJJ fighter "Striker and a Grappler" highly skillful at both and he happens to be the champion in a very competitive bracket.
Posts
