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

When I did my Original Review of the iStudy PMP® application, I was pretty happy with it.  I said for $10, go for it.  One feature I really liked was the questions were completely random.  So, each test was unique.

So, how does v2.0 compare to v1.0?

Here is what changed between the two versions:

Do I think you should get it?  Again, I say go for it!
It’s only $2.99 for 550 questions and this version is even better than the last.

Last night we deployed HueCubed v1.0 to Production.  A year ago, I had an idea for a product that would inexpensively help people study for the PMP® Exam and other certifications or tests.  The result?  HueCubed.

HueCubed is a web application which will display randomized flash cards.  Upon reviewing the question, you simply click on the Flip button.  The card flips and displays the answer.  You then have several buttons you can click.  If you click on skip, incorrect, or correct, the system will log your selection.  You can then, at any time, click on Check Progress.  If you click on Flip, the card flips to the other side.  If you click Back, you will navigate to the previous card.

So let’s say you want to see your progress and click Check Progress.  Your choices will be broken down by categories of study.  Think of them as mini decks of cards.  There is one big deck (All) and then you have it broken down into 23 categories.  At any time, you can click one of the squares and it will return you to that card for review.  e.g. if there were 28 cards in a deck and you click on 14, you can go directly to card 14 of 28. (see image)

Anyway, I can go on an on about this product.  The idea came to me after I was asked over and over again to recommend products to help people study for the PMP® Exam.  Sure, the products are out there.  But, each one had something I didn’t like or thought could be improved upon.  I wanted something Simple, Powerful, and Cost-Effective.  So, I created HueCubed.

The last year has been hard.  I went through 3 development teams before I got a winner.  I’m not demanding or anything.  It’s just hard to find the right team sometimes.  I spent countless hours eating my own dogfood.  I created UI wireframes, I created fnctional designs.  I created a WBS.  I used a Kanban to manage my work.  We iterated and iterated.

HueCubed v1.0 was my critical path.  All of the required deliverables are there.  It will be a solid platform to build upon.  I hope I didn’t drive me wife too crazy with the idea of this first product.  I still have a group of offerings I want to provide.

In closing, I want to quote 2 great people who inspired me to do what I did.

Jason Calacanis said “Starting is easy; Finishing is hard.”

Seth Godin wrote “Pick a budget. Pick a ship date. Honor both. Don’t ignore either. No slippage, no overruns.”

I had an idea on March 22, 2009, that seemed simple enough to finish.  How hard could it be?  The answer was “very”.

I had a budget and stuck with it.  I gave myself 1 year to get it done or move on with my life.

I bootstrapped the effort and got it delivered.

HueCubed v1.0 went live at 11:28PM last night.
Yep, March 22, 2010.

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 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.

First Tweet from HueCubed.com

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.

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