How To Prevent Your Project From Hemorrhaging

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?

Creeping Ever So Closer To Closure

As my startup project is creeping ever so closer to its closure and the actual launch of the product happens, I'm feverishly completing activities late into the night.  It's not easy working crazy hours to get this done.  My family goes to bed, I drink a pot of coffee, and get to work.  An entrepreneur (Jason Calacanis) once said starting is easy; finishing is hard.

He wasn't kidding!  As a project manager, managing my own project for a product related to project management, you can see there is a little irony.  But, I really think this is going to help a lot of people and it will be worth all of the sleepless nights.

Today's activities included

1. Initial rebrand of the HueCubed twitter page
2. Initial load of the new HueCubed logo to the website
3. Set up the blog component
4. Post 1 free question and answer (with the plan to do it daily)
5. Load 10 questions and answers into the database

Mission accomplished.  I completed the 5 activities and am ready to call it a day (night).  Though we're not quite ready to launch, please feel free to follow me or subscribe via the RSS feed.

Thank you all; and to all a good night.

The Pain Of IE6 And Application Development

Yesterday, a vendor advised my client the new feature requested to be implemented doesn't work quite right with Internet Explorer (IE)6.  The feature works fine with all "modern" browsers but IE6 is a major pain point.  You may ask yourself why we're even having this conversation.  Well, because we're talking about the Federal Government.  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?  Do you embed a browser check in your code and advise the users they need to use a different browser?  Do you "fix" what would otherwise be a clean implementation by making it work with IE6?  I've seen issues with IE6 happen over and over again.  Even with my website(s), I pay attention to legacy Internet Explorer traffic.  I'm happy to report my IE6 traffic is 11% of my overall traffic, down from 21% a year ago.  Still, I will continue to test IE6 until it falls below 10%. What lesson can we take away from this?  Do your homework!  The vendor should have done an analysis (or known stakeholder system requirements) before implementing the new feature.  Catching it in QA is too late.  A little due diligence or prototyping could have saved a lot of time and money.  Knowing the current customer base, the vendor should have known this feature would not be accessible by all and advised the customer.  What would you do?

I would love to read your comments or feedback.  Please post them below.

Regards,

Derek

Refine Your Process If You Must Deviate From It

As I mentioned in my post yesterday, 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. Merriam-Webster defines process as a series of actions or operations conducing to an end.  If you are unwilling to modify your process, the deviation is unworthy of being done. I've had a vendor tell me they didn't need to document their processes because they were agile.  (Notice the lack of an uppercase A in Agile).  Leveraging Agile concepts does not mean a lack of documented process.  IF the customer tells me they see the greatest value in delivering documentation, what is this vendor going to respond with?  Sorry, we won't deliver value?  If you use Waterfall, you may be used to generating more paper.  You have to consider documentation on a case by case basis.  Some customers have legitimate needs for documentation and other have wants.  Now go back and read that last sentence again.  Needs...Wants...

I personally like to go light on documentation.  What I need and what the customer needs are usually two different things.  That being said, I like to understand the rules (governance) before I start anything.  The Microsoft Visio document I included in my last post was a good example of a high level governance (functional flowchart) document. After completing the flowchart, I then detail each activity in a separate document.  What is the input and output?  Is there a formal deliverable associated with the activity? The idea behind the separate document is you won't need the flowchart to describe the process.  For those who have successfully navigated a SOX audit, you know what I'm talking about.  But I digress.  The flowchart activities I documented are not groundbreaking.  The process in this case is an Agile Scrum process with a few defined quality assurance decisions points.  You do not need to go into the Nth degree to understand this process.  Identify some touch points where the vendor and customer interface.  Identity some decision points.  That's it!

I've done these flowcharts for several customers.  I've created them for both Waterfall and Agile development approaches.  If you're looking for a free Microsoft Visio template, which you can edit at will, you can download it here. I zipped it to make downloading easier.  If you're looking for other free templates or worksheets to use on your project or program, you can download them there.

What do you think?  To document or not document.  That is the question. I welcome your comments or feedback.

Regards,

Derek

Pillar Technology is Hiring

Pillar Technology is ramping up several large projects in Columbus, OH and Detroit, MI. They are in need of a bunch of people and have opportunities at many different experience levels. They are looking to hire immediately and will entertain people who want to work 1099, W2 hourly, or become full time employees. Pillar's strength is the quality of their people and are pretty selective about who they bring in. They are looking for people that are technically excellent, have great communication skills, and will fit in well to the Pillar culture. Go to Mike Cottmeyer's blog for more details.

To be considered for their technical positions, you need to be an experienced Java developer or technical tester and you MUST have experience with TDD.   Other skills they are looking for are:

• Jboss Portal
• Portlet Specification
• XML Jibx parser
• Rest
• Strong UI / JSP experience
• Maven
• Team City
• EasyMock

The more of these you have the better.

Need more information?  Of course you do! Go to Mike Cottmeyer's blog for more details.

Review of the iStudy PMP App for iPhone and iPod Touch

Disclaimer: Though I recommend this product, I am not financially benefiting from this review.

The iStudy PMP is an iPhone and iPod Touch application specifically designed to help those aspiring to pass the PMP® Exam.

If you have seen sample questions from the PMP exam, you know the pain points; double-negatives, lengthy questions, what is the "best" answer...  When I prepared for the PMP Exam a few years ago, I spent several hundred dollars for a program that simulated the PMP exam.  I'll admit, it worked great!  But, what if I could have passed the exam and also saved several hundred dollars?  If this application was around when I was preparing to sit for the exam, I would have purchased it first.

Interface

iStudy PMP contains 200 questions that intend to replicate the PMP exam. The interface is clean and it allows the user to concentrate on answering the questions.  If you come to a question you're not sure about, you can Mark (skip) it.  I thought I ran into some problems with the Mark feature.  Swiping my finger across the screen didn't always advance me to the next card.  After some practice, I realized it was just me. The application was working just fine.

Not to get ahead of myself, but there is a results page to see correct/incorrect results.  One thing missing is a similar navigation page showing the skipped questions.  You're given the opportunity to go though the skipped questions at the end of the exam but you can't see how many skipped you have.  You just have to go through them one by one.  I contacted the creator of the application and he confirmed this is something to be resolved in a future update.

Tests

iStudy PMP has 4 different modes designed to cater to different learning styles.

Normal - This mode displays all 200 (randomized) questions and allows you to sequentially browse. You can go back and forth as many times as you wish, but you have to go in sequential order.

Exam - This mode is similar to the Normal mode minus the fact you have a time limit of 4 hours to answer all of the questions. You can go back and forth between questions as many times as you need to change answers.  If after 4 hours you have not answered all of the questions, the exam will automatically end and your results calculated.  This is good because if there was one thing I took away from doing full length practice exams, they help you build up your stamina.

Stress Test - This is a pretty interesting mode. I like that you choose the number of questions you want to answer (out of 200) and an amount of time you wish to allow yourself.  If you fail to answer a question before the timer hits zero then that question is marked as incorrect and the application advances you to the next question.  Let's say you set the stress test to 15 questions and 2 minutes per question.  Your stress test will be done in 30 minutes.  Pretty cool.

Knowledge Area - The PMP Exam assesses your competency from 9 Knowledge Areas. This mode is like the normal mode but it allows you choose a specific knowledge area.  This is a nice feature when you know you have specific knowledge weaknesses.

Results Screen

Once you have completed a test, or if you intentionally end it, you will be presented with the Results screen. Here you will see whether or not you passed the practice exam. Results will be broken down by knowledge area so you can see where you need to improve.  All questions will be listed as either correct and incorrect with an option to display the entire question and answers.

Summary

For $10, I say go for it!  One feature I really like is the questions appear completely random.  So, each test should be unique.  If you're interested in this app, you can get it from the iTunes store, go to www.istudyapps.com or click here.

Management Team Wants Versus Needs

Maslow

Mike Cottmeyer of Leading Agile wrote an excellent post, posing a question: Why wouldn't a management team embrace a set of methodologies so focused on giving them what they need the most? I took a few minutes to digest the question and then compared it to my prior experiences implementing Agile on a management level.  Though I have seen the desire of a management team to embrace Agile, allowing more value to be delivered, I also saw them take pause and throw up roadblocks. At the moment they believed the top-down command and control structure would be weakened by bottom-up empowered teams, delivering value suddenly didn't appear to be as important. Though I appreciate the necessity of a management team to provide strategic vision, I believe tactical implementation should be left to those outside the group. The hierarchy of wants, not needs, for the management team differs from the implementation team, if we want to admit it or not.

The key question asked is why wouldn't a management team embrace a set of methodologies or approaches so focused on giving them what they need the most? My answer is I believe it is because delivering value is NOT necessarily what they WANT, it is what they NEED.

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