Have you ever stuck your neck out and get no support?  Did the trust among that team start to break down? I’ve seen it happen first hand and Geoff Crane wrote an awesome post over at Papercut Edge about it.  He called it the too-common cycle of apathy.

The post hit a nerve with me. At my previous engagement, the Engineering Department was used to being railroaded by management. Promises were always made on their behalf and they found themselves working long hours and weekends. If they didn’t make the goals, those who made the promises would never take ownership. If goals were miraculously accomplished, the same person(s) would jump into the spotlight. After I was brought on board, I didn’t have a problem looking a Director or CIO right in the eye and telling them I disagreed with them. Sometimes they backed down and sometimes they didn’t. But everyone at that company knew I was honest and would speak up if I didn’t agree with something. Everyone knew I was looking out for my people, my department, and my company. I believe positive change rolls up hill, just as sh*t rolls down.  Though I’m no longer with that team, I have no regrets for backing them up and providing support when they needed it most. Those who bullied so many are no longer there either.  Though there was an attempt to silence my voice by decapitating my team, others in the organization saw through the ruse.

I think sticking your neck out is worth the risk. If I think you’re right, I’ll support you.  By doing that, I build trust with my teams. With trust, my teams will do anything for me. With that, anything is possible. What can I say, everyone is happy but the party you had to confront in the first place. Yep, it’s certainly worth it.

Thank you Geoff for getting me fired up.  Now go check out his site!

image courtesy of Papercut Edge

This post is in response to a post written by Jennifer Bedell on the PMStudent blog about goldplating.

Goldplating is very common in application development and can be very expensive. If you’re dealing with Waterfall, it’s a little more obvious when it’s happening.  Some may argue, but I’ve seen it happen in Agile as well.  I’ve sat across the table from a vendor and asked, are you prepared to roll back every one of these changes?  Their eyes get big because why wouldn’t the client want these changes?  Well, too many times a developer is in the code and they think, while here, why not make this additional change we planned to do next month.  Or, now that I’m here, it makes a lot more sense if I do it like this versus what we originally thought.

In short, Jennifer wrote about goldplating caused by testers. She asked

why is it always the developers who get blamed for goldplating? When you consider the cost of change increases as the project timeline progresses, it becomes evident that, in addition to increasing scope, goldplating by a developer can also be costly. Goldplating by a tester can occur when a tester goes beyond the stated requirements in an effort to produce a “quality” product. A tester may feel that their suggestion would improve the customer experience so they log this in the defect log.  While their suggestion may do exactly what they envisioned, if it was not within the scope of the stated requirements, it becomes a form of goldplating or “feature creep”.   A tester’s job is to ensure that a quality product is delivered, but many testers rely on their own definition of quality rather than using the requirements to define quality…

I’ve seen team members at every stage of the Software Development Life Cycle (SDLC) attempt to goldplate, with the best of intentions. Regardless of where you are in your development process, any time there is a requested change to the baseline, there should be a control mechanism.  I call that mechanism a triage. Be it the customer or a customer representative (Project Manager, Product Owner, or BA), someone needs to vet anything and everything which could impact the baseline.  These changes need to be prioritized and reviewed.  I’m not saying changes should not be made.  I’m saying they need to be properly vetted.  Changes impact the schedule, the budget, and in the end…customer satisfaction.

Without this control point, I think you’re guaranteed to see creep somewhere in your project and you will see it begin to bleed time, money, or both.

Yes, we certainly want to deliver the greatest value to the customer. But, creep increases risk and that’s not value.

Am I just a control freak or do you agree with me?

As we enter the 3rd day of Washington DC being shut down, I ask myself why.  It’s 2010, for crying out loud!  You’d think they would find a way to keep things operational.  Just because government employees can’t report to physical locations, doesn’t mean they can’t work, right?  From the OPM.gov website, Federal agencies in the Washington, DC, area are CLOSED.

This means…

• Federal agencies in the Washington, DC, area are closed. Nonemergency employees (including employees on pre-approved leave) will be granted excused absence for the number of hours they were scheduled to work. This does not apply to employees on leave without pay, leave without pay for military duty, workers’ compensation, suspension, or in another nonpay status.

• Telework employees may be expected to work from their telework sites, as specified in their telework agreements.
• Emergency employees are expected to report for work on time.
• Employees on alternative work schedules are not entitled to another AWS day off in lieu of the workday on which the agency is closed.

---

Now, this post isn’t necessarily about government employees, a majority of whom will just stay at home and get paid.  Don’t get me wrong, I care a lot about my government counterparts.  Some of them work darn hard and are up late at night keeping things running.  This is about all of us who support the government.  In a day and age when the government needs to be nimble and innovative, I sit here knowing I’m not necessarily going to get to bill an hour of my time, while the Federal agencies in the Washington DC area sit idle.  No, I certainly can’t do 100% of what I was hired to do but I have things I could have caught up on.  I have a constant rotation of priority deliverables that arrive in my inbox, ready for my review and recommendations.  I don’t need to be on site to read a document about cost and schedule variance on CLIN 123, in order to deliver value.  But guess what, that’s exactly the case.  If I’m not physically on site, I have to get special approval to do any work and bill any time.

As Jhaymee (@TheGreenPM) Wilson tweeted today, the recent Snowmageddon in DC brings visibility to the Federal Government’s lack of a risk management policy, which includes teleworking.  I believe the policy should include contractors.  My FedGov PMO identified a strategy to keep us operational, in the event H1N1 hit the agency.  The strategy was a mandate from higher in the government.  So why then wouldn’t there be a plan to keep us operational in the event of inclement weather?  This just proves, in cases like this, the Federal Government doesn’t plan to fail; It just fails to plan.

This week I really wanted to turn up the volume of things I wrote about.  I have a lot to say (and write) about project management and if you missed reading my blog on a given day and don’t have an RSS feed or follow me on Twitter, you’d have to go searching in the archives to find it.  I don’t think that’s good enough.  I should make it easy for you to read what I write.  Hopefully, this week in review will help you find something new while you enjoy your coffee or tea.

1/28/2010

Seeing Value From The Customer Perspective

I don’t care if you’re using Agile, Waterfall, or other methods to deliver value.  What is important is you understand your process and what mechanisms provide the greatest value to the customer.  Just because a process does not appear valuable to you, it does not mean the process does not provide value…

1/29/2010

Refine Your Process If You Must Deviate From It

If you’re looking for a free Microsoft Visio template of a Sprint process workflow, which you can edit at will, you can download it here.  As I mentioned in my post Seeing Value From The Customer Perspective, if you think you need to deviate from a documented or understood process, rewrite or refine your process to account for the deviations…

1/30/2010

The Impact Of Social Networking On Project Management

Good leaders do not operate in a vacuum. They exchange ideas and information with people. Offer free information and it will come back to you tenfold. Listen to knowledgeable people and then make a more educated leadership decision… In this post I compared the traditional communication paths and how that process is turned on its ear, thanks to social networking…

1/31/2010

This Is How You Know When To Kill A Project

A personal rant about paper telephone books and how I never realized, until now, who the real customer was. There is a very similar parallel between the newspaper industry and the printed phone book industry.  They both believe or promote the scarcity of information.  That scarcity justifies cost.  To the contrary, we now live with an abundance of information.  That information is freely distributed and reaches a broader audience…

2/1/2010

The December Numbers Are In For PMPs

Yes, the December numbers are in.  December 2009 numbers for Project Management Professional (PMP®) certifications were published and it looks like there will be over 400,000 holding the certification in 2010…

	December Totals
New PMPs (December 2009)	5,403
New PMPs (YTD)	75,107
Total Active PMPs	361,238

2/2/2010

And The Best Methodology Is

I recently commented on two blogs that address similar topics.  Jesse Fewell wants to empower teams to succeed, equip managers to lead, and enable executives to unlock the secrets of high performing organizations.  Jesse wrote a blog post offering the real reasons behind the methodology wars.  It’s an insightful post and I would recommend you go and read it…

The other blog post was from Mike Cottmeyer, someone I turn to on a regular basis to find inspiration and wisdom within the industry.  Mike wrote a blog post asking Why is Agile so hard to sell? Again, it is a very good read and you should set aside some time to read some of his writings…

The Pain Of IE6 And Application Development

There are legacy applications out there that were built on IE6 and it’s not an easy migration.  There are some Agencies which ONLY use IE6 and the users don’t have permissions to install a new browser.  So, what do you do?…

2/3/2010

Updated 10 Step Help To Submit PMP PDUs

All PMPs need 60 PDUs during a CCR cycle so don’t put it off until the last minute.  I document the process on how to claim your require 60 PDUs…

2/4/2010

Using Common Sense With Documentation

Though I really love good documentation, going heavy on it does not guarantee a successful project.  My recommendation is you spend a little time identifying documentation that truly meets your needs.  More importantly, identify documentation that truly meets your customer’s needs…

2/5/2010

Managing Risks and Opportunities

Washington DC is in the process of getting 20-30 inches of snow, over the next 24 hours.  Though I know you can’t foresee all possible issues which may occur over the course of a project, you should make an honest attempt to identify them in order to open a dialog with your stakeholders.  Has weather ever delayed your project or pushed it over budget?…

Washington DC is in the process of getting 20-30 inches of snow, over the next 24 hours.  The forecast hasn’t changed all week.  If anything, it’s gotten worse!  At no time did the weather service say this weather event was going to miss us.  The Beltway has been in the cross-hairs of this system since the computer models discovered its formation.   That leads me to write about risks and opportunities.  Actually, for today, it’s just risks.  When working on a larger project, you should always have a discovery session early on that will capture potential risks and opportunities.  Once these events are identified, you should quantify their values.  You’ll also want to capture the probability of each.

Once you’ve captured a risk (or opportunity), its value, and its probability, you’ll know better if you’ll be planning acceptance, avoidance, mitigation, or transference.  I’ll save that process and definitions for a later time.  Right now, I want to talk about snow.

Yesterday at the meeting I hosted, we discussed our contingency plan for today.  Even before the meeting, we knew we were going to get hit with this weather system and it would impact the schedule.  This was no longer a risk but an issue.  The issue was relevant because our vendor has a contract deliverable due today.  Inclement weather was not annotated in their risk register so it was up to us tell them how this would play out.

Though I know you can’t foresee all possible issues which may occur over the course of a project, you should make an honest attempt to identify them in order to open a dialog with your stakeholders.  Local schools systems plan for snow days.  They have documented strategies to deal with these events because they’ve learned their lessons.  Shouldn’t your projects as well?

This snow storm is going to mess with a lot of people and a lot of projects, over the course of the next few days.  I hope we all learn a lesson from it.

Has weather ever delayed your project or pushed it over budget?  I would love to hear about it.

Regards,

Derek