Pictofigo Promotion

I've been working with Pictofigo for a few months now.  I give them ideas for drawings I think others would find helpful.  In turn, I get access to some pretty cool (and original) stuff.  It's quid pro quo at its best. There are currently over 900 drawings available for free on the Standard Pictofigo site.  In addition to those, there are 13 Premium items.  These items range from a few free desktop wallpapers to Scrum posters and traditional project management posters.  What's the difference and why pay for stuff?  The standard site has drawings at 72 dpi resolution, perfect for a blog, website or presentation.  The Premium site has drawings at 300 dpi resolution, suitable for print or products.  Yes, I do offer links from my site to CafePress, if you want printed posters.  But, the actual high resolution drawings are available if you want to print out a few posters at a lower overall cost.  I got a notice today that Pictofigo is going to run a half off promotion on their premium content.  Because I like to encourage and support entrepreneurs, I wanted to write this quick post.  If you're in the market for some original drawings, look them up.  They are constantly iterating on the site so check back often.  If you have an idea for a drawing or poster, give them a shout.  If you want, you can send me the request and I'll forward it along.  To be clear, I am not Pictofigo.  I merely love what they do and want to see them succeed.

HT: Pictofigo

Describing the SDLC

SDLC

While assisting an IT department through a Sarbanes-Oxley (SOX) audit, I had to document an organization's Systems Development Life Cycle (SDLC). The SDLC includes activities and functions that systems developers typically perform, regardless of how those activities and functions fit into a particular methodology.  Many assume SDLC is referring to a software development process.  In turn, there's a lot of debate about different development practices and approaches.  For example, when I lead Scrum teams for an organization, as part of an overall SDLC, all of the Scrum activities took place during the Implementation phase.  When changes were deployed to the Production environment, the Support team leveraged Kanban.  From Planning to Analyzing to Designing, they leveraged a Waterfall process.  It all began with a request for a change. Because a picture is worth a thousand words, Pictofigo has created a SDLC poster, with a little input from me. You can either purchase it from CafePress as a poster or you can download it from the Premium Pictofigo site.

Meeting with GAO

After finding out the Government Accountability Office (GAO) was coming to pay our program a visit, I was also told to work with a small cross-functional team to collect all of the data to meet their requests.  There was a list of recommended executive actions and we had to prove how we were satisfying those recommendations.  To visualize our progress of collecting the data, I used a physical task board and sticky notes.  I would call it a Kanban but we really didn't have any work in progress (WIP) limitations.  The board was comprised of 4 columns:  Backlog, WIP, Blocked, Done.

As of last night, everything was in the done column and I even had one team member come up and shake my hand.  For some reason, I think there may have been a lack of confidence that we could identify and collect the data requested.  With some leadership, inspiration and clear goals, we got it done.  Though I'm not at liberty to say exactly what we supplied them, the requests they made were not unreasonable.

I've been through a SOX audit before so I understood how an audit works.  Provide proof that you do what you say you do.  Be able to explain why you do it.  Now, what you do and how it aligns with how others think you should do it is another story.  But, if the auditor is not satisfied with how you do it, they will make a recommendation on how you can meet their expectations.  Here is the important thing.  An auditor does not care what you say you are going to do.  They care what you say you've done or do.

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?

Seeing Value From The Customer Perspective

I recently sat in a meeting between a vendor and client, where the client was attempting to communicate their need to route new work deliverables to an existing Change Control Board (CCB). The contractor came back and said they believed the CCB in this case would not provide value and perhaps it should be bypassed.

Note to all vendors: Just because a process does not appear valuable to you, it does not mean the process does not provide value. The use of the CCB provides a (formal) control point helping to prevent unauthorized work and cost overruns. This goes further then just having a client billed for unauthorized work. Any work done without prior authorization has a risk of negatively impacting project schedule, cost, or quality. The mere act of doing unauthorized work impacts the scope.

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.

If you think you need to deviate from a documented or understood process, rewrite your process to account for the deviations. If you are unwilling to change your documented process, the deviation is unworthy of being done.

I created the Visio diagram (above) a few months back to help both the customer and vendor visualize what we were trying to accomplish.  The challenge was implementing Scrum in a very formal and controlled environment.

I certainly recognize many don't have such a formal process.  Instead of CCBs, you may call them Product Backlog Review Meetings.  Counter to this, you may have a very fluid and simple software development life cycle (SDLC).  If so, you still need to understand your process and you still need to communicate with your customer.  Understand what their highest priorities are and deliver.