• Why do we need detailed project plans?
• Why do we need detailed cost break-downs?
• A basis of estimate?  What’s that?  Do I really need one?
• How do I get my customers to pay for those Project Management costs?

Rather than offering a lot of consultant type wisdom, I thought you might find some recent news articles a bit more informative and instructive as ‘case studies’.

• New York City’s $720 Million CityTime Project a Vehicle for Unprecedented Fraud Says US Prosecutor
• IT fraud at water affairs department
• Senate panel supports requiring Lockheed to absorb cost overruns
• Worsley overruns adds to embarrassing list of fumbles
• County Bigwigs Rant About Multimillion-Dollar Cost Overruns

Mark Rabideau (L)
Judah Mogilensky (R)

SEI Partners Acknowledged for their Years of Service

The SEI Partner Network hosted its annual meeting and luncheon in Portland Oregon last week. During a luncheon on Wednesday 23 March 2011, SEI Partner Network Manager Lisa Masciantonio and SEI Director and CEO Paul D. Nielsen acknowledged SEI Partners for their service and commitment.

During this luncheon, the SEI recognized PEP for having been an SEI Partner since ‘the beginning’. Partner tracking and the Partner name were established by the SEI 15 years ago.

Note: In the spirit of full disclosure, PEP has actually been working with the SEI and SEI related products since before 1992.

You may also feel, as I do, that one greatest challenges faced by process professionals involves developing effective process designs and simulating those designs prior to implementation. The ability to try a process out before it goes live; prove to yourself, and others, that the process is cohesive (works and flows as planned); and will run smoothly is crucial to success.  Not to mention, it aids in maintaining your peace of mind.

As a huge proponent of Open-source and Free-ware, I have searched the net recently for tools to help in this realm.  And as you might have imagined, they also needed to be Open-source or Free. What follows are a few tools that I think bear a closer look.   I have not used them all, but I do think they merit a detailed review by anyone interested in designing and simulating processes as part of their plan for implementation.

Enjoy!

BPMN Tools

Gliffy

Business process modeling software helps new and experienced users create BPMN diagrams quickly. Our business process tool looks like office applications, so users can start using business process software immediately. Gliffy is offered as JIRA or Confluence plugins or On-line.

Oryx Modeling Platform

Oryx is a web-based, extensible modeling platform, licensed under open source terms. With Oryx, you can create diagrams in many different modeling languages and share them with your partners, colleagues and friends. To start modeling you need no installation–your model is just one click away. So, why not start modeling right now or check out existing models?

ProcessMaker

ProcessMaker offers its business process management software in a single, award-winning edition called the ProcessMaker Open Source BPM Platform. Use ProcessMaker as best suits your needs: 1) Download Open Source Code and use it without support, 2) Sign Up for an Enterprise Subscription Plan and get professional support and additional features from us for your PM installation, or 3) Subscribe to ProcessMaker in the Cloud let us manage your installation for you.

Activiti BPM Platform

Activiti is a light-weight workflow and Business Process Management (BPM) Platform targeted at business people, developers and system admins. Its core is a super-fast and rock-solid BPMN 2 process engine for Java. It’s open-source and distributed under the Apache license. Activiti runs in any Java application, on a server, on a cluster or in the cloud. It integrates perfectly with Spring, it is extremely lightweight and based on simple concepts.

TIBCO

TIBCO Business Studio™ Community Edition is a free, standards-based, business process modeling environment that enables business experts to model and simulate business processes and their supporting data and organization models. (Eclipse based)

CMMI, unlike Six Sigma, provides a path or macro-level roadmap for improvement.  The path basically is presented or communicated using two major views.  Overly simply stated, these views represent ways of looking at specific improvement options or approaches; one is refered to as staged, the other as continuous.

Warning: For those CMMI linear-thinking “attorneys” who may be reading this posting, I recommend you skip the next three paragraphs or so. Better yet, you might wish to skip to a different article or posting.

Truth be told, the views or representations of the CMMI are neither truly staged nor continuous; more accurately to my mind, they have historically been “constageuous”.  The staged view providing a roadmap across maturity levels; and the continuous representation providing maturity definitions within the process areas themselves.  Two roadmaps.

As an economist (which I guess my Economics degree qualifies me as) I would say the CMMI views/representations are similar, or analogous,  to macro and micro economics.  However with the advent of version 1.3, that analogy weakens greatly… and the continuous view today seems, to me, to add much less value than it did earlier. Excepting to say, it continues to emphasize that organizations can improve where they want, by process area, and that the process areas are now rated more similarly across both CMMI representations.

Be that as it may, the 1.3 release of CMMI continues to provide a clear, albeit not very concise, roadmap for organizations to build their improvement programs upon.  The provided roadmap is something of a checklist (a really big checklist) highlighting what processes ought to be implemented and validated first, second, and so on.  That’s the good news.

The bad news is that far too many people use the checklist without ever bothering to develop an adequate understanding of business context and needs- this is where Six Sigma comes in (more on that later). When the CMMI checklist folks get all revved up, they begin using the CMMI as a union work to rule document and build all manner of confusion, inefficiencies, and frustration into the systems they are supposed to be improving. Not good! But this happens with undeniable frequency and goes a long way to explaining CMMI’s reputation as being ponderous and bureaucratic. However in fairness to the authors of the CMMI, these problems are user problems, not model design problems.

Six Sigma on the other hand does not provide an equivalent roadmap or checklist set of functions.  What it does provide is an outstanding set of methods, tools, and techniques for gaining an understanding of a business process, measuring it, and validating the success of the effort.  It is worth noting that the CMMI offers no similar tool set; although, it does discuss some of the approaches and techniques integral to Six Sigma.  As practitioners of Six Sigma are aware, these tools and methods can be invaluable in gathering information about how work is being performed, modeling its as-is and to be states, establishing success criteria and measuring the effectiveness of the implemented change(s).

The down-side of Six Sigma is that without a CMMI-style roadmap, organizations run the risk of addressing sophisticated process improvements for which there is inadequate infrastructure to support or sustain the improvement(s).  Without a roadmap, improvements can be uneven and isolated.  Infrastructure can be ignored.  Improvements can even become counter productive when viewed in the enterprise context.

The bottom line is that Six Sigma practitioners can and do benefit from roadmaps such as those provided by CMMI. CMMI practitioners can and do benefit from excellent tools and methods such as Six Sigma. I guess that could be called synergy.

Again, as I noted at the outset of this series, should you have any queries, concerns, or items you wish to see discussed, please use our contact page to let me know, or leave a comment.

Given that CMMI high maturity level and six sigma organizations typically use statistics packages in assisting them to manage and adjust business trends and flows, I thought our readership might find these links to open source stats packages to be of interest.

N.B.: Minitab and SPSS, perhaps the pre-eminent software packages in this arena, are both highly functional, broadly used and extremely expensive; both are also biased to the windows operating system (something I try not to use).

Hopefully, these packages provide a somewhat helpful listing of options.

If you are aware of other tools or toolkits that should be added to this little list or if you have any queries or concerns, please use our contact page to let me know.

In order to better enumerate the sources of Six Sigma and CMMI individually, below is a brief listing of each set of ‘roots’. (Please be aware: Neither listing is 100% complete nor 100% agreed upon by practioners from within each field!)

Over the next several posts, I will discuss in this topic in greater detail.  Again, as I noted at the outset of this series, should you have any queries, concerns, or items you wish to see discussed, please use our contact page to let me know.

Let me start by saying, obviously, there are differences. The mere fact that both approaches and industries exist ought to provide a clue to the fact that there are uniquenesses. But what are the most crucial uniquenesses?  The key distinctions which I intend to discuss include the unique:

Over the next several posts, I will discuss in greater detail each of these uniquenesses, such as I view and understand them.  Again, as I noted at the outset of this series, should you have any queries, concerns, or items you wish to see discussed, please use our contact page to let me know.

I guess I should note, it is my opinion that both CMMI and SixSigma efforts primarily involve human change, and human change is more about people and sociology than it is about numbers.  So in that spirit I will begin this series by noting that possibly the most obvious area of synchronicity between CMMI/SixSigma involves the recognition and need for high quality management communication.

Both worlds acknowledge and emphasize that good, effective communications form a key component in building effective process improvement programs.  A good process improvement communications network relies upon both clear and understandable message transmissions (just like an effective computer network does!).  Simply stated, conflicting messages, erroneous, or irrelevant information are the greatest contributors to process improvement project failures.  There is little more damaging to the success of a project or program than confusing, conflicting communications.

CMMI and Six Sigma both stress that preparing your organization for its improvement effort requires consistency in all messages and communications be they verbal, written, non-verbal, direct, or indirect.  It is essential that new or pre-existing process improvement concepts, tasks and efforts be stated in terms readily understood by those who are expected to embark on any change.  This means everyone must effectively be “in the loop”, including those you might assume are not going to be impacted.

If everyone is to understand your plan(s), it goes without saying, that those plan(s) must be communicated in terms everyone can understand!  Do not err by focusing on a too narrow subset of the population for your communications, better to over communicate than to ‘miss-communicate’.

Over the next several posts, I will discuss in this topic in greater detail.  Again, as I noted at the outset of this series, should you have any queries, concerns, or items you wish to see discussed, please use our contact page to let me know.

To set the stage, I must admit that as a high maturity lead appraiser I often hear questions regarding the relevancy of CMMI to Six Sigma (6sigma). Although it would be nice to have a simple reply to CMMI’s 6sigma relevancy, unfortunately, I do not.  In truth there really is no simple “Yes it is relevant” or “No it is not relevant” response. I should note here, that is where the title for this little series comes in… CMMI is, in fact, more or less relevant to 6sigma; it really is not a “yes” or “no” thing.

I guess that lets the cat out of the bag, doesn’t it?  You can stop reading here if all you want is my bottom line on the question; because I just provided it.  My hope is that you might remain curious enough to hear more on where things fit with each other and where they might not. It is doubtful that I will address all the “hits” or “misses”. In my series posts on this subject, I will, however, try to highlight some of the bigger boulders.

So that’s it for the teaser article.  “Watch this space for more” as I attempt to address the question of whether CMMI is relevant to SixSigma.

Perhaps it is the linear thinkers in the CMMI world that cause people to think like this tweeter.

My patience with #CMMI zealots has finally run out…stop wasting my time with your endless documentation requests!

When I read this tweet I thought: “Who exactly makes endless CMMI documentation requests anyway?”

There is nothing within the CMMI or any related standard that says you should do stupid things and, endless documentation certainly fits nicely into the stupid things category. Certainly the CMMI and similar guides emphasize the requirements for management and teams to be trained, know which tasks are essential, and perform those tasks with discipline and effectiveness. But none of these requirements need result in endless documentation requests. So, what might cause them?

Could it be that the appraisers referred to by the tweeter quoted above are linear, check-list thinkers? Are there “union work to rule” appraisers out there? My 20 plus years of CMM/CMMI work would say, yes. Are there people out there teaching and coaching CMMI related concepts who are not engineers or developers but rather single minded process attorneys? Certainly there are. But, the CMMI world is no different in these deficiencies than the PMP, Agile or other “standards” world.

Successful implementation of any standard, method, or approach requires a thoughtful, holistic implementation with a nuanced understanding of the targeted business and application environment. An architectural approach with an eye towards a cohesive end state is also essential. Check-lists, linear thinking, and legalistic work to rule thought processes are not only a reason for failed CMMI programs but also a cause for cost over runs, poor performance, and frustration to all those involved. And those same traits ensure failure in any domain. The CMMI is not alone.