Whenever I tell people that I am both a PMP and an Agilist, many look at me as if this had to be some deep, dark secret.

How could one study and practice a formal project management methodology and also use Agile?

Guest post by Erika Flora

Years ago, I heard this great quote that has really stuck with me and become somewhat of a mantra. It is as follows:

There is no limit to the good you can do if you don’t care who gets the credit.

General of the Army George C. Marshall

Staff Sgt. Conrad Begaye recognized for bravery under fire in Afghanistan - by US Army Africa via Flickr

What a fabulous concept! Often, we are so worried about our own jobs and careers that we don’t take the time to think about those around us and make sure we help them get what they want. Ever since I started making a conscious effort to really “let go” of who gets the credit, my work attitude has completely changed. In addition, the way my team and others around me view my work has completely changed. They realize that I am their champion, and they work hard to perform to the best of their abilities. Rather than spending time worrying about whether executive management sees all the great things I am doing, and position myself accordingly for that next great promotion, I focus on mentoring others and helping those around me get recognized for their hard work. I actually spend part of my work week thinking about how I can bring visibility and kudos to the efforts of my teams.

Too often, when employees are surveyed in their companies, many of them say that they feel their work is not valued or that no one has told them in the last six months that they appreciate them. How terrible! The best thing we can do for our coworkers, direct reports, colleagues, and project teams is to find creative ways to show them our thanks and make sure everyone in our company knows that they are making a valuable contribution. We all love to get praised for our hard work. Make sure you are taking the time to proactively do that for others.

Many companies have put great examples of this concept in place. When I worked with Pfizer, they implemented something called a Pfish program where you could send a Pfish card to a colleague for a variety of reasons (being a team player, going the extra mile, or even just making your day). Every week, the people that had received a Pfish card were entered into a raffle for a gift card. However, the very best thing about the Pfish card program was that the recipient’s boss was copied on the email that they received. It was a really fun program and one that made employees feel special and appreciated.

However, you don’t need a company program to show your appreciation for others. Here are some really easy things you can do to make a big difference in the lives of those around you – Submit your project team for an internal company award, external “Project of the Year”, or other award. There are lots of professional organizations that look for a variety of award submissions and, many times, are excited to get new submissions from companies or people they have not heard from before. Log onto LinkedIn and write unsolicited recommendations for people you have enjoyed working with. Send a short email to a coworker’s boss thanking them for going the extra mile on a difficult project. Start a “Thanks a latte!” newsletter that thanks your team members by name and post it up at work, maybe even leave a small Starbucks gift card on their desk before they get into work. The more creative and silly, the better! You will be surprised by the results. It seems counter-intuitive, but we as project managers end up shining the brightest when our teams shine. What other examples have you seen or done to brighten the day for those you work with and help them get the kudos they richly deserve?

Erika Flora, PMP, ITIL Expert
erika.flora@GoBeyond20.com
www.GoBeyond20.com

It’s said there are no new project management sins, just old ones repeated. It’s also said that we don’t learn the lessons from past projects and this must be true, otherwise why would we keep making the same old mistakes?

Project management as a whole has paralleled somewhat the changes we have witnessed in photography. Project management also has been a skill for the few, with the barrier to entry being quite high. However, the barriers are being reduced and the chance for abandoning “point and shoot” project management is here!

Projects are naturally networks of commitments. Learn how to bring reliability to your projects by paying attention to promising conversations.

In an article at Projects@Work, Tom Mochal discusses how enhancement work not directly related to a project should be added to the managed portfolio…

Anita Wotiz is the guest blogger this week over at the UCSC Extension in Silicon Valley Project Management blog. She published great post titled “An unrepeatable success?” Read it here.

It was great to hear about the project, specifically the lessons learned and trying to relate them to my own experience.

I wouldn’t write the first set of factors off as things that can’t be duplicated. Sure, it’s easier in some cases because these things fall into your lap, but these can be influenced to some extent. Paraphrased:

1. Good team (competent, cooperative) –A PM can sometimes influence who works on their project, and ensure they are competent. Cooperation and team spirit is largely influenced by the PM, in my experience.
2. Exciting work –Not every project is glamorous on the face of it, but the PM can and should figure out how to position the product being created to the team by selling them on how much value it will add for the end users, and how their individual and team contributions make it possible.
3. Full access/utilization of previous work –Again, this usually doesn’t fall in your lap, but it’s amazing to me how many project managers don’t spend enough time during the planning phases trying find previous work that can be re-used. Many seem to want to re-invent the wheel with each project.

As for the other factors, paraphrased:

1. Don’t constrain the project to a preconceived solution –Three points; I see this so many times, where the sponsor and stakeholders have a preconceived notion of what the solution should look like before they even fully understand the problem! Granted, sometimes there are real constraints that are necessary. I think it’s human nature to start coming up with possible solutions very early in the process, and difficult to avoid. Personally though, I’ve found the best results come from forcing yourself to focus strictly on the need/problem during early planning, including the charter, preliminary scope statement, and initial requirements gathering processes.
2. Good WBS creation and decomposition, bottom-up estimating –Bingo! This agrees completely with my experience about what helps make a project successful. I’ve had a lot of luck in the past using a delphi-style method of estimating, where we go through each task in a room with the experts who will be performing them, and each person writes down an optimistic, likely, and pessimistic point estimate. I take all the estimate sheets afterwards and roll them together, ask about any outliers, and can usually come up with pretty good ranged estimates with a solid grasp on standard deviation and confidence levels.
3. Management cost/time buffers available –I agree that it’s critical for the sponsor/customer to realize that buffers are there for a reason…they are not just downtime or waste, they are crucial components of a good project that can handle the inevitable risks that will arise.
4. Collaboration –It sounds like Anita was able to get the whole team to collaborate on scheduling by using post-it notes on the wall. I think that is excellent, although alternative methods may work just as well to have the team collaborate on schedule and task dependencies.
5. Iterative Development –This is a benefit I’ve used and seen in my projects too. If you can push out iterative releases that are functional, you can start getting feedback from the customer and make subsequent development based off a real foundation, instead of a theoretical one. Writing code to specs is one thing, but if you can immediately test it against an initial release of the pieces it has to integrate with, you’re way ahead of the game.

Kimberly Wiefling had an article today on Projects@Work (www.projectsatwork.com) giving us a taste of some hard-learned lessons when dealing with project sponsors.

I’ve always loved Kimberly’s sense of humor and highly recommend just about anything she’s written. This is a great example of education a la entertainment. Check out her book too, you can buy it from the PMStudent book store by clicking on the image to the left.

In short, her exploits yield the following lessons learned with regards to project sponsors:

1. Don’t assume who has decision power. Be clear on who the real sponsor is.
2. Don’t assume your sponsor wanted this project. If their boss mandated them to sponsor the project, it’s going to be tough. In Kimberly’s example, ideas for projects were generated by executives, and the CEO made the decision of what to implement. The ideas for improving one division came from a different division, etc. That means the sponsors were put in charge of a project they didn’t come up with….can you say sabotage?
3. Don’t assume your sponsor knows what their role should be. Insist on coaching the sponsor and letting them know exactly what support the project will be asking from them.

Great article Kimberly!

Cutting’s Edge is one of my favorite project management blogs. Thomas recently posted on the cost of project success. I enjoyed the examples of the construction of several wonders of the world as projects and their often overlooked consequences on the project teams that built them.

Thomas draws out a parallel to contemporary projects, and how in some or many cases project managers will actually plan on over-utilizing staff in their planning, or not see it as enough of a risk to take serious action.

His point is well taken, and I would like to add the pressure from the other side. I have worked with many team members who felt it is a status symbol to have been the one to work the most hours in a given week. It’s like keeping up with the Joneses. A good project manager has to be able to detect this. Signs include:

• Spends an inordinate amount of time socializing with co-workers
• Often points out explicitly or implicitly that they are working a lot of hours
• Often points out explicitly or implicitly that they were the first to arrive or last to leave for the day

Many people who work 10 to 12 hour days get the same or only slightly more than those who work 8. Productivity is a ratio of how much value was added over the time it took. Aim for more productive people, not people willing to sacrifice their personal lives by achieving less productivity over more time.

Dave Garrett recently wrote on the concepts expressed by Aaron Shanhar in his book, Reinventing Project Management. The gist is that the common triple-constraint model of managing cost, schedule, and scope is not enough. As I like to put it and in Goldratt’s words, necessary but not sufficient.

I have not yet read Shanhar’s book, but have a few initial thoughts based on Garrett’s description.

The notion feels right. I have observed a few specific behaviors that may come about because of the framework of incentives set up by the traditional approach. First, quality assurance seems to be an afterthought or necessary evil in many projects, if it happens at all. I agree with the notion that the triple constraints are efficiency-focused. They set up incentives to meet the requirements, even if those are the bare minimum. Many times, scope is reduced as a result of cost cutting efforts, and they are looking for whatever will provide barely satisfactory results. Activities are dropped without a thorough analysis of what the impact on quality, team morale, etc. might be.

Second, I have known many project managers to define success as sticking to the requirements, even if they are very bad requirements. There’s no incentive to put a lot of effort into quality requirements if a project manager knows they will still have met scope, schedule, and budget. In other words, you can have a failed project which meets all three constraints. Interesting….doesn’t sound like success criteria.

I agree we need a better model with which to think about projects holistically. I look forward to reading Reinventing Project Management, and learning more.