Goodbye PMO Email

Today was my last day with the PMO.  I couldn't help but send an email to everyone before the SysAdmin locked all of my accounts. I've already gone to security and turned in my badges.  I've already talked to everyone I could find.  It is Friday, ya know.  You can't expect everyone to be in the office.

As I went from office to office, people were telling me how much they liked what I wrote.  So, rather than having is die on a Government email server, I figured I would just publish it here.

Today is the day.

I'm all packed up and ready to go. Today I will be drinking your coffee, eating your free time, and rambling on about something unrelated to the original conservation. Ya, sounds like a usual Friday.

Thank you everyone for the lunch yesterday. You all need to do that more often!

Over time, I've realized that project management is a lot less about trying to control things like schedule, budget, and scope and more about building relationships and helping others reach their goals.  After I leave, if there is anything you think I can help you with, please let me know.

All my best,

Derek

Drawing by Pictofigo

True Measure of Character

I started my day slightly frustrated.  Upon offering my verbal resignation (last week) to my immediate superior, the company that I contact for gave no (written) response.  I was pretty certain my superior would inform them.  Because I wanted to be professional and also ensure they knew, I then offered a written letter or resignation to both my superior and the corporate office.  Again, I received no response.  As each day has passed, my customer (the PMO) has grown increasingly agitated knowing that I made a company a lot of money and they aren't even recognizing that I'm leaving. Because I felt obligated that the entire PMO knew I was leaving, I sent out a group email.  I've received multiple emails (from members of the PMO) wishing me well and thanking me for my service.  I even received an email from the vendor, who I wasn't always kind to.

I think the true measure of character is when things don't go as planned.  I tweeted that and Dennis Stevens responded "It isn't character until its tested".  So, I'll revise my statement.

I think the true measure of character happens when things don't go as planned and it is tested.

I'm still refining the statement but I'm glad I wrote it.  It made me feel a little better.  Through all of this, I don't plan to say who I contracted for.  There is no value in people knowing their name.  The checks were in my bank account on time and for that I am grateful.  They allowed me to take care of my customer and in turn I made them a lot of money.

Many were surprised that I am leaving.  The PMO probably would have kept me until it was either dissolved or the contract ran out.  I understand how a Government PMO works but my heart is still with Agile education, transformation and adoption.

I did finally get an email, today, though it wasn't what I expected.  I expected something short like "Best of luck in your future endeavorers."  Instead it read "Don't forget to turn in your badge by 11am on Friday".

Dennis, I think they failed the test.

Drawing by Pictofigo

PMO Analogy

As my tenure with the PMO comes to an end, I've had an opportunity to reflect on the last two and a half years.  What I realized was how much the PMO was like the U.S. Congress.  If I imagine the organizational structure of the PMO I've been supporting, I can imagine the CIO as the President and the PMO Program Director as the Speaker of the House or the Senate Majority Leader.  Beneath the Program Director are the Division Directors (Committee Chairs) and then members of the PMO (Congress in general).  What I've found interesting is many (not all) have their own agendas and motives.  Gridlock, not collaboration, is the norm.  Now, am I talking about the PMO or Congress?  I'm not trying to paint the PMO or Congress in an unfavorable light.  To the contrary, these people are all SMEs in their respective areas.  But they've seemed to have forgotten the common goal.  They've forgotten who the customer is.  In both cases, it's the American people. From my perspective, when you're trying to deliver value, you need to consider all of the options, regardless of your convictions.  I was the sole Agile evangelist in the PMO.  Think of me as a lobbyist representing the American people.  I did what I could to help the Government understand and to be receptive to new ideas.  But what the PMO failed to grasp was Agile is much more than a way to deliver software products.

I think Michele Sliger put it very well:

Being agile means that teams are working in ways that allow for change in order to better work together and provide a more useful and meaningful product to the customer.

My final days with the PMO will be like a long retrospective.  What went well during this engagement? What could be improved in the next engagement?

HT: Michele Sliger

AgileLIVE Webinar Series

Not seeing the productivity gains you expected?  Are you and your stakeholders losing confidence in your team's ability to deliver?  Are you sure you are measuring the right things? VersionOne and their Moving Agile into the Mainstream webinar series provides proven techniques to help you and your team with the tough issues facing agile managers, scrum masters and product owners.  Fifty-minute sessions feature case studies from teams that have succeeded in using agile methods to efficiently create better software.

Today, I saw "The Hybid PMO" by Sanjiv Augustine and Roland Cuellar of LitheSpeed

Even when agile methods succeed unequivocally at the team level, middle-management still faces two major, continuing challenges: managing a hybrid portfolio of agile and non-agile teams, and reporting progress upwards to the executive boardroom. How can PMOs bridge the gap between executive management weaned on plan-driven methods and predictability, and teams operating with agility in the face of uncertainty? How can they create a consistent reporting framework applicable to both agile and non-agile teams and communicate all-around progress effectively?

Sanjiv and Roland shared principles and techniques for the Hybrid PMO, and discussed some of the crucial management steps in establishing such a group, based upon their decade of experience in helping firms adopt agile at enterprise scale.

It doesn't matter if you want to learn from leading Agile pundits or just looking to get a few PMI PDUs.  This webinar was very enjoyable.  VersionOne will be uploading the webinar in a day or tow for those who were unable to join the live presentation.  All of this was FREE!

So, head on over to VersionOne and check out the other webinars from the series, from the likes of Dr. Alistair Cockburn, Bryan Stallings and Valerie Morris -  SolutionsIQ, and Michael Spayd - Collective Edge Consulting

The awesome Image and some of the content for this post courtesy of VersionOne

Call Agile Whatever You Want

Last year, when a vendor was asked to submit a Statement Of Work (SOW) to address the Statement of Objectives (SOO), they came back with a very interesting presentation.

Upon completing our Lessons Learned at the end of the last period of performance, we have something that will solve all of your problems.

Now, I don't know about you, but whenever someone says that, I get very suspicious.  All is an absolute and absolutes are red flags.  It's a particularly large red flag, considering the customer was not invited to participate in the Lessons Learned session(s).

What was the proposed solution to All of the customer's problems?  The vendor called it "agile" (with a lower case "a").

Seriously?  That's all you have?  Agile will solve all of the customer's problems?  I sat quietly and said nothing of having several years of experience actually using Agile and leading Agile and Scrum teams. (Note that I prefer to use a capital "A")

Needless to say, the vendor had no experience following Agile principles or leading Agile teams.  The vendor, in my eyes, failed to educate themselves or the customer on the value Agile can deliver.  Over the course of the next year, they shied away from face-to-face communications and all of the things the customer would see value in.  They continued to keep their functional teams in silos and nothing changed.  After a few months of the customer and myself telling them they were not following Agile principles, they admitted they were doing an undocumented agile-like-waterfall hybrid.  After a few more months of telling them they were not following any kind of Agile "like" process, they lamented and said they were now following a waterfall process.

NOW? I asked myself.  This vendor couldn't even define what done meant, let alone explain what processes they were following.

In the last few months, three major events have happened to the program I support.

1. The CIO retired
2. The Program Director retired
3. The program budget was just cut over 10%

A new CIO and Program Director are now in charge of the program and realize they have a lot less money to work with.  So, how are they going to turn this around?

Let's fast forward to a few weeks ago.  The new Program Director calls an all hands meeting.  What is going to change?  She started the meeting by making a profound statement

Communications is key to our success.

If we do not communicate, we will fail.

What is she asking us to do this next year?

1. The vendor will not have their contract option year exercised
2. The PMO will be re-oriented away from its current functional configuration
3. 8 Cross-functional Project Teams are being created
4. Each team will include (at a minimum) a product owner, a PMO lead, and technical point of contact(s)
5. Regular communications will take place for each project team, activities and statuses will be reported up to the program level, and then disseminated back down to the rest of the PMO
6. The Progam Director is giving teams of motivated individuals the environment and support needed, and trusting that we will get the job done

At no time did she ever say Agile.  But, is it really necessary to?  As long as we begin to follow Agile principles, you can call it whatever you want.  I see this first step as a big step in the right direction.

Like the image?  Find it at Pictofigo

Week of the Elephant

I'm not sure of the origin, but as I was watching an adventure race years ago, I heard an awesome quote.  One of the contestants was asked how he was able to trek a 300 mile course, navigating so many obstacles through so much adversity.  His reply was "even an elephant can be eaten, if you do it a bite at a time".   Though I try not to whip that quote out every time one of my colleagues appears stuck on a project, I do like to bring it out for special occasions.  I think this may be one of them. 3 things happened this week, that rate the reference:  Work during the day, school, and work during the night.

By day, I'm an adviser to a Federal Project Management Office.  I'm not in a position to tell government employees what they should or should not do.  It's my job to advise and support them in any way I can.  This week, they asked me to attend an invoice meeting.  This wasn't a surprise.  Upon reviewing the vendor's invoice from last month, I wasn't satisfied the Billing of Materials (BOM).  There was a lot of stuff ordered and I am very particular about asset management.  I recommended a 7 figure short pay.  I don't think it's important to be specific about the amount.  My client decided to do a 6 figure short pay.  At the 2 hour meeting, we went line by line and the vendor offered corrective actions for items I recommended not be paid.  I accepted some of their proposed corrective actions but they still need to deliver on some promised if they want all of the invoice paid.  One month down, another to go.

Our son started Kindergarten this week. We weren't sure how he was going to take to it.  Until Monday of this week, we were convinced he was going to be crying at the bus stop, wanting to say home with Mommy.  We figured he'd come around in time.  Monday arrive and so did the bus.  He ran aboard almost before we could give a hug and a kiss goodbye.  He returned some 8 hours later and ran off the bus with a big smile on his face.  The adventures that boy had!  Here it is Friday night and he's fast asleep.  One week down, 16 years to go.

At night, I find myself reading the PMBOK® or project management blogs and writing PHP, CSS, and JavaScript. Back in March of 2009, I realized I wanted to create something to help project managers on a grand scale.  That's when I started doing mockups and wireframes for what was to become the HueCubed engine and PMPrep Flashcards.  One year later we launched version 1.0.  This week I worked on 2 new jQuery elements and tonight deployed v1.2.12.  The web application has been progressing nicely and both customers and affiliates are signing up.  Though I never thought we'd get to v1.0, I now do an iterative build and deployment at least once a week.

For those interested, I still have plans for a PMPrep Exam Simulator web app and Prince2 Flashcard web app.  And yes, we're going to be doing an iPhone application.

Graphic: South African Tours and Travel

Agile is in the PMBOK so it must be true

Yesterday, I was having coffee with Jesse Fewell and we discussed, among other topics, how the PMP® or Certified ScrumMaster (CSM) credentials legitimize many in the eyes of stakeholders. This is a sore spot for many, particularly for me.  Experience and project leadership trumps a certification any day of the week.  But, for those of us who believe we know what we're talking about, a credential is sometimes a necessary evil.  As I advise a Federal PMO on a multi-year project, I have grown to accept that progress can be slow and expensive. Things can be so slow and expensive, we rarely get to see actual value delivered.  Rather, successes are measured with earned value. Sometimes, I think it's just the nature of the beast. But, it doesn't have to be that way.

You can only imagine my excitement when a vendor proposed using Agile to deliver the next (year) software increment. The PMO I advise has many PMPs but only one CSM...me.  I'm not going to go into the details of the project.  But, how could the opportunity be seized to leverage Agile?  Rather than answer that directly, I'll ask a question.  If you believe in the Agile Manifesto, how would you convince people with no experience with Agile or Scrum (but lots of experience with the PMBOK and Waterfall) that you know what you're talking about and that Agile is a viable option? I would propose that you make sure you can communicate with stakeholders in a language they understand. If you start using terms like Sprint, ScrumMaster, and Burndowns, when they understand contract periods of performance, project managers, and EVM reports, you may lose that essential stakeholder buy-in.

One of the first things I would recommend you say is "Agile is actually in the PMBOK". If your stakeholders are PMPs and they believe the dogma of the PMBOK, you'll have their attention. It's not called Agile but it is there. In Chapter 2 (Project Life Cycle and Organization) of the PMBOK, you'll read about Project Phases, specifically phase-to-phase relationships, and then even more specifically the iterative relationship.

...only one phase is planned at any given time and the planning for the next is carried out as work progresses on the current phase and deliverables.  This approach is useful in largely undefined, uncertain, or rapidly changing environments such as research , but it can reduce the ability to provide long term planning.  The scope is then managed by continuously delivering increments of the product and prioritizing requirements to minimize project risks and maximize product business value.  It also can entail having all of the project team members (e.g. designers, developers, etc.) available throughout the project or, at a minimum, for two consecutive phases.

For the Agile pundits out there, does that sound a little familiar?  For those who believe the gospel of the PMBOK, is it reasonable to believe Agile is an approach that can be considered?  Agile is not a bunch of voodoo for the wild and undisciplined.  It's an excellent opportunity to deliver value.

My First Year In A Directive PMO

Today I realized I've been supporting and advising a Federal Government PMO for a whole year.  Prior to that, I was the Manager of Software Engineering at an online company that had recently gone public.  I was the sole PMP (Project Management Professional) and  sole Agile Evangelist. Upon my leaving that company, I told my superiors they really needed a PMO if they wanted to offer consistent results, measurable improvements, and increase stakeholder satisfaction.  It was hard at first to shift gears, away from a private profit-driven organization, to Federal governance-driven organization.  At the private company, it was all "being creative" to meet unrealistic goals set by those not versed in best practices.  Since there were no other PMPs, I felt like the lone sheriff in the Wild West.  Now that I'm dealing with the government, I'm surrounded by other PMPs.  There is policy, process, and governance.  Everyone knows their jobs very well.  They know best practices. So you can differentiate the type of PMO I work in compared to others, I've included the 3 basic types below with their definitions.

There are 3 basic types of Project Management Office (PMO) organizations are [1] supportive, [2] controlling, [3] directive.

1. Supportive PMO generally provides support in the form of on-demand expertise, templates, best practices, access the information and expertise on other projects, and the like. This can work in an organization where projects are done successfully in a loosely controlled manner and where additional control is deemed unnecessary. Also, if the objective is to have a sort of 'clearinghouse' of project management info across the enterprise to be used freely by PMs, then the Supportive PMO is the right type.

2. Controlling PMO has the desire to "reign in" the activities - processes, procedures, documentation, and more - a controlling PMO can accomplish that. Not only does the organization provide support, but it also REQUIRES that the support be used. Requirements might include adoption of specific methodologies, templates, forms, conformance to governance, and application of other PMO controlled sets of rules. In addition, project offices might need to pass regular reviews by the Controlling PMO, and this may represent a risk factor on the project. This works if a. there is a clear case that compliance with project management organization offerings will bring improvements in the organization and how it executes on projects, and b. the PMO has sufficient executive support to stand behind the controls the PMO puts in place.

3. Directive PMO goes beyond control and actually "takes over" the projects by providing the project management experience AND resources to manage the project. As organizations undertake projects, professional project managers from the PMO are assigned to the projects. This injects a great deal of professionalism into the projects, and, since each of the project managers originates and reports back to the Directive PMO, it guarantees a high level of consistency of practice across all projects. This is effective in larger organizations that often matrix out support in various areas, and where this setup would fit the culture.

Definition Source:  http://ezinearticles.com/?expert=John_Reiling