The Law of Attraction and Project Management

The Law of Attraction states that we are attracted to that which is of the same nature as our thoughts. As an example, I recently bought a new car, a Mitsubishi Outlander. Before I got the car, I never noticed Mitsubishi's on the road. They aren't the most popular car in the US. Now that I have one, I notice them much more. My thoughts are about them, so I see them more, I attract them.

So how does this apply to project management? Our thoughts can influence how we see our project. If we only think about the negative things, that's what will dominate our project, or at least that's what dominates our observations.

Here's an example of how you can use this to on your project. Most projects involve change. A good technique in change management is identifying and using your early adopters. If you think about being an early adopter, you will attract the early adopters among your stakeholders. You can then tap into them to help move your project forward.

So think positive, it will make a difference.

How do you Test?

I came across this quote from Shigeo Shingo; "Inspection to prevents defects is absolutely required of any process but that inspection to find defects is a waste."

I brought up the quote in a webinar I was giving on Six Sigma last week and it brought some interest from the audience. So how do you test you product?

I've been in many QA roles through my career. Writing test cases, reviewing test results, re-engineering a testing process. The best approach that I've found is to get the end users involved in testing early in the process. The folks that are using the software (or whatever you're building) should write the test cases on how they would like to see it tested, as the requirements are being captured, not after the product is developed. Scott Ambler refers to this as Test Driven Development.

On a related note, Dave Prior has a post talking about being done and being done done. So when is testing done? Is it after development is done, i.e., waterfall? Or is testing integrated into your development process?

Quality should be built into the product, not inspected for after completion.

How Much Process?

So I gave to presentations this week on different topics. Monday I was the presenter at the Kansas City Chapter of PMI. My presentation was on Scrum. Today I talked about 6 Sigma on the PMI IT & Telecom Special Interest Group's monthly webinar.

One of the principles behind Scrum (and really all agile approaches) is to put personal interactions before process. Don't get bogged down in the process, just have enough to keep things moving forward. Six Sigma assumes a more rigid set of processes.

So where's the balance? That of course depends. Today someone asked me if you can apply six sigma if you don't have any well-defined processes. My response was no, you have to get some processes in place first before six sigma could help you.

But you can get to focused on process. Lean talks about eliminating waste. To much process can introduce waste. Do you have to produce specific documentation that doesn't add value? That's what you want to get rid of.

The trick is figuring out what is just enough. Map out your process. Look at all the inputs and outputs. Then decide what isn't adding value to your product. That's what you should get rid of.

Barriers to Innovation

I came across this video that addresses some of the barriers to innovation at NASA.



Do any of these conditions exist at your workplace? People not stepping out of their comfort zone? Silos? A process that inhibits innovation?

I was presenting an overview of Scrum last night at the Kansas City PMI Chapter meeting. One of the things I stressed is the Scrum (and any agile approach) is supposed to be flexible; using Scrum doesn't lock you into specific steps. As the Agile Manifesto states "Individuals and Interactions over Process and Tools" Does your project management process allow you flexibility to be innovative?

Reputation

How often do you think about your reputation? It's something that you may not focus on, but it doesn't take much to ruin it, as Michael Phelps recently found out. Blogger Andy Beal shows how quickly Phelps killed his reputation in this post.

In the Navy we had a saying; "it takes a whole lot of atta boy's to make up for one oh crap!" The idea is that you can work hard to build your reputation but one mistake can screw it up.

As project managers, we don't have direct authority over all the resources we need for a project. We have to rely on influence as a form of leadership to reach our project goals. Without a good reputation, we make our job more difficult.

So how do we build our reputation? Integrity is important. Keep promises. Deliver what you say you will. When you hit an obstacle, be open with your stakeholders. Admit it when you make a mistake.

When you're trying to decide a course of action, think about the impact on your reputation. Cutting corners on testing? Padding your expense report? Having one to many drinks at the company dinner? As Michael Phelps found out, one little slip up can have big ramifications.