Moving The Matrix...

Moving the PM Matrix to ... http://rcubed-pm.generation-joe.com/ my new Wordpress MU install!!! Woot!

Be sure to check it out :)

-Optimal Optimus

Google Wave ... DAAMMN!!!

A tweet from one of my friends yielded this video on Googles new Wave application. Looks like communication and collaboration just got a shot of combat stimulants.

I am looking forward to leveraging this tool in the near future.

What will those crazy kids at google come up with next.

- Optimal Optimus

My Favorite business books... No Surprises here...

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.

-Optimal Optimus

An Amazon Link:


* 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

As promised - Primer on Agile Project Management and SCRUM

Check out this SlideShare Presentation:

I presented this on 051509 to the San Diego PMI Chapter during their annual PMI Conference.

-Joe

Primer on Agile Project Management and SCRUM

View more presentations from Joe Riego.

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)

Ok Grasshopper ... When you can take this pebble from my hand...

On the Merits of Certification:

At its very core, Certification is a piece of paper that says you have been exposed to or have been trained to a certain level of proficiency in a certain body of knowledge.

I won't question the value of the certification. I for one think that there is intrinsic value to being trained and certified, Certified Scrum Master (CSM), Project Management Professional(PMP) whatever. For me the issue is that the connotation that one can be certified in something like the PMP or the CSM and they walk away a master in the art/discipline is specious.

All PMPs are not created equal all CSMs are not created equal. All those credentials really mean is that they have exposure and ideally a better than average understanding of what the methodologies offer as value propositions to an organizartion and how to implement them, to what levels of success may vary.

In the case of the CSM, I think the real weakness of the certification is that because its "Agile" it is some how easy and fast a panacea of sorts. This connotation sets erroneous expectations of what someone walking around with a CSM is or is not capable of. Maybe a more hardcore approach to the certification is warranted. Hopefully the discussion with the village elders of the Agile Community will come up with something that better protects the integrity of the skilled practitioner and brings more value to the table.

For the PMP, while the certification is much more rigourous with the concept of an auditable period of time before qualifying and continuing education requirements, that really only scratches the surface of what it means to run a project or be a project management professional or a leader in general which is really what project management provides at its basest level, and any leader worth is salt will tell you no one can just magically wave their leader wand and bam you are a leader, something about blood, sweat, and tears needs to get mixed in there,

Let's use a metaphor for this issue (everyone loves metaphors), I look at it like the mall strip Karate Studios and how many people have black belts these days? 2k and 1 year and bam you get yourself a black belt. They were certified in "attaining" knowing a certain level of skill, practiced it in a prescribed time, and a governing body approved said level of skill.

I have studied and trained for more than half of my life never got more than a brown belt at any one school of martial arts. To the uneducated many would discount me as a dabbler or amateur until they check my references as a closed door student to several highly respected masters of the martial arts, renown by blood and by deed. Maybe one day I will pony up 2k and join the certification class but then the master's would look at me funny and say so what's this about you want to start your own school too huh? (like that?... yeah like that and all it implies.)

Certifications are always nice to haves. I for one am far more concerned with practical skill and experience than fancy papers even though they can make me look really cool. My real value lies in how I apply my skills and expertise not whether or not I have a pedigree and I sleep-walked through it all. Black belts like that get weeded out eventually, usually by a kick to the neck and a short nap on the canvas.

Does that mean I don't value a certification process? No but I do check under the hood and kick the tires a couple of times just to be sure things are where they are supposed to be.

Remember in Kung-Fu the series Grasshopper's journey didn't end when he was able to take the pebble from his masters hand... It was only the beginning. Oooooo...Zen-esque Mystical stuff now what would be the billable for that?

- Optimal Optimus

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

Communication Discipline

Communication

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.

-Optimal Optimus

Dependencies, Critical Path, Float... who needs em?

* Dependencies?
* Critical Path?
* Float?

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.

- Optimal Optimus

A post on Corporate America

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


• Never give up


• Fight for what's right


• Don't be a passive aggressive dick


• Take Risks


• Don't believe your own press

- Optimal Optimus.

Project Management and Web 2.0

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.

For the record I am following the following tools

*dekiwiki
*ning
*boonex

Either way its definitely an interesting time to be a PM.

"The PM Matrix" Integrated tith Ning's Social Network Platform


- Optimal Optimus

An Agile Understanding

Some excerpts from a presentation I gave to people looking for help with Agile Project Management and SCRUM. Credit to the Dilbert folks J of course.

So what is SCRUM and Agile Project Management?

Not going into any overly specific jargon or canned answers:

• Agile is a Project Management Methodology that focuses on
• Iteration
• Interaction
• Transparency
• Product Delivery
• SCRUM is a meeting and project tracking format used heavily in organizations that practice Agile Project Management

Traditional Project Management and SCRUM/Agile Project Management

• Traditional Project Management places emphasis on
• Milestones
• Artifact management
• Historical reporting
• Minimizing Change
• SCRUM/Agile Project Management places emphasis on :
• Iteration
• Product oriented delivery
• Transparency
• Extensive Product Owner Involvement
• Change is expected and incorporated in the process to provide value add.
• Does not rely heavily on historical or artifact management but rather how much work remains moving forward.

The Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Pasted from <http://agilemanifesto.org/>




Iterative Development

• Developing End to End, a working product with the assumption that improvement and gains can be made throughout the development iterations
• The product may not have 100% of the feature set but could be used in production
• The general concept is to flesh out and improve over each iteration to meet the requirements/expectation of the business



SCRUM… What's it all about

• SCRUM is the default process for Agile Project Management and has the following assumptions in its pure form:
• Senior Team Members
• Dedicated Team
• 100% Product Owner Involvement
• Product Backlog
• Sprint Backlog
• Daily Meeting
• The Burndown
• Sprint Planning Meeting
• Pigs - Committed
• Chickens - Not Committed



The Daily Meeting

• 15min or less
• What are we doing?
• What is planned?
• What is blocking us
• Take a look at the "Burn Down" or whatever graphical representation of the project the team uses
• That’s it. No muss no fuss

Pitfalls of the Daily

• "Lets talk about implementation details" - Good Idea, wrong time
• "Logorreha" - The idea is to keep meetings short so the communication used is supposed to be boiled down, too much talking and team members not on your portion of the sprint loose interest and slows morale
• "What are we supposed to be doing" - No product owner no sprint is what I say, he's the guy/gal that breaks ties on what has to happen and should be the definitive authority on the project Prioritizing and Deprecating as the process moves forward.
• "Scrummaster does that? Right?" - Scummaster doesn't do very much but act as the alarm for the team and escalate issues and run interference for the development team (Pigs and Chickens)



The Burn Down

• This is the Graphical Representation of Agile it measures velocity of completing a sprint.
• It looks to work remaining as the metric as opposed to how much is done.
• Seems counter intuitive but from a line perspective it allows the resource to see what is remaining and how much its going to take as opposed to looking at the Gantt and seeing what was done and have no idea how much its going to take given the current time frame.



Question 1:

• Are Unplanned items usually unexpected production support related issues? What else is unplanned?
• Well from my perspective we prioritize the production issues and weigh them against the constraints to hitting the sprint as negotiated by the product owner.
• If the product owner says this product support issue trumps the feature the issue gets the effort and the feature gets pushed to the product backlog for reallocation .
• Remember because of the Transparency (in this case finite resources and product owner involvement) Delivery expectations match what the product owner wants.
• Note: as soon as the Product Owner assigns the task to a sprint and gives it a priority it stops being unplanned.

Question 2:

• If we determine part of the way into a sprint that existing code (Created before the Sprint) needs refactoring, should that be included as an unplanned item
• In the sprint the User Story should take into account potential unplanned tasks and reflect it in the Complexity Points (If you use them)
• At the very least be brought up as a blocker in the Daily for discussion on inclusion into the sprint and requiring Product Owner resolution.

Question 3:

• If we start work on a story and realize the initial estimate of the story was way off, do we modify the total number of points in the sprint?
• I wouldn't. This should be brought up in the daily that the sprint as it currently sits is in jeopardy and that the product owner needs to re-assess the Sprint as a whole and reprioritize the Tasks/User Stories as it would meet the expectations of the Product Owner and end users.

Question 4:

• If we start work on a sprint and the product owner decides he/she doesn’t want a story anymore do we modify the number of points in the sprint?
• Yes. However it's been my experience that the Product Owner never wants to take things off without adding more. The reason is typically to assign more work.

Question 5:

• What sort of requirement gathering process do you go through before you start a new sprint?
• I have a pre-planning meeting with the Product Owner and Lead Engineers, review the product backlog, and then pick the brains to identify additional work.

Question 6:

• If we have a project that is only 1-2 weeks worth of work would you recommend setting this up as a spring? If not how would you choose to handle it?
• I would assess is it really an independent initiative or if I could roll it up as a User Story in the forthcoming sprint.

Death by Band-Aid

Working in the industry I've noticed a few things. People always look at Band-Aids vs. Solutions. Even within the realm of project management or some might say particularly in the world of project management.

Classical Band-Aids:

• Communication is poor, instead of increasing frequency and quality of interaction an often response is to document it.
• Schedules are slipping consistently, so lets through more people/money at it.
• Morale is low, let's give em the pep talk and a hand shake, a pat on the back, and tell them to soldier on.

Sound familiar? Of course it should these wouldn't be "Classical" Band-Aid approaches to business issues if they weren't seen often enough to approach cliche.

So why Band-Aids over a solution? Why?

Solutions are:

• Expensive
• Complicated
• Often Embarrassing

How so?

Band-Aids are easy. Low Hanging fruit in the consultant world. Often picked to show immediate gains and validate hypothesis. But cutting to the root of a problem or issue takes more effort, more commitment, and lastly ownership and the last thing anyone wants to do in the "corporate" world is own up to a failing in their organizational operations.

Expensive - Solutions often mean paradigm (yeah I used the word paradigm) shifts in how they approach the issue/problem. These changes mean re-training, resistance and sometimes buying new machines, software, and people. All daunting prospects. How does all this stack up if we can go to the classical Band-Aid of saying ok we need to document this...

Complicated - Solutions at least good ones are end to end endeavors. They address a business problem/issue end to end. They aren't stop gaps. This means it crosses over organizational silos, human capital relationships, and the political barriers in addition to their overall pure business impact. Honestly who wants to step on the feet of the powers that be to solve a business problem that has been affecting the higher ups but obviously has been assumed as "nature of the beast". It doesn't get much more intimidating than that.

Embarrassing? How so? In order to solve a problem you must admit that there is a problem to begin with. Telling a "C" Level exec that his decision to adopt a particular stance on technology is killing his competitive advantage is the nightmare for any management type and similarly a line engineer telling his co-worker in production that their process may not be revealing the end all to the products woes.

So what to do what to do?

Get over it.

An unpopular viewpoint I am sure but I didn't join the the workforce to be popular. I have tons of friends. I joined to workforce to solve problems and provide an unquestionable value proposition. I leverage Project Management and Scientific Management principles to enact such solutions. Sometimes it casts light to places where others would rather remain within the umbra and there are consequences for that, I bear many a scar from such altercations. But it changes nothing. Solutions not Band-Aids are what is called for in times of doubt and uncertainty.

You don't go to the hospital with abdominal pains and say "My insides feel funny? Can you slap a "Band-Aid" on me doc? I think I can handle it"

You wouldn't want that doc to say "Oh I've seen this 1000x no problem, here's a Band-Aid call me if it gets worse"

Call me crazy but I would be looking for like "Ok. Let's see tell me the syptoms, when did it start, how intense, and I am going to assume you want me to fix this, ah ha based on this I think you have a ruptured appendix. I am going to schedule surgery to fix this... I hope you have insurance... ;p "

What's the alternative, soldier on and die a septic death? Pass.

Solutions are much more desirable than a slow agonizing death.

The video is from Heartbreak Ridge(1985) I thought it appropos.

-Optimal Optimus

Situational Awareness

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.

-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

Scrummtastic!!!

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

- 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

Lean In...

So I was looking for some more topics to touch on in the blog. After some thought I decided to go with dealing with change.

Not too long ago I attended a PMI Component Conference with Bob Young one of the founders of Red Hat Linux, acting as the final keynote speaker. The topic of his keynote speech was "How the Internet will kill us all" which would have been more aptly named "Lean In or Get Out".

So what does that have to do with Project Management?... Tons.

Project Management from my perspective is all about expectation management and expectations often change, embracing this change or "Leaning In" to the changes as opposed to fighting them goes a long way to ensuring responsive and effective operation.

Often we spend a lot of energy trying to fight change as opposed to seeing it as an opportunity to improve or gain a better understanding of situations for gains in the long run. It is part of the human condition to view everything with a personal filter on the situation, it’s a developed skill to be able to separate one from that filter and look at things rationally.

Change is to business as breathing is to life one cannot exist without the other. Markets evolve, needs change, expectations are met or adjusted all a reality of doing business. The question we face is are we going to take this reality in and look for opportunities to move forward and realize gains or do we close ourselves off and pray that the change passes by and stagnate.

I opt for the embrace. I am a trained project manager, I am familiar with many styles and tools to effect my trade but I never allow myself the false luxury that my experience gives me a "fool proof" solution. Granted I have more than a few principles I try to follow but when the tires hit the pavement I am always looking for where the road is going and how my tires will grip the road, always discerning whether or not I have to take a pit stop and adjust the tread I have on for the road ahead.

I "Lean In". Not only am I a trained project manager but I am a trained fighter and "Lean In" has another meaning . In a fight everything is constant change. Combatant shift and feint changing the scope of the fight in hopes of putting their opponent off balance. "Lean In" is something that a judicious fighter employs when he accepts some of the "change ups" an opponent and turns it to his advantage, typically by leaning in to an oncoming strike robbing it some of its power or effect to deliver a telling counter strike or to begin a series of offensive strikes in hopes of defeating the offending party.

The alternative? Staying still? That gets you knocked out.

-Optimal Optimus