I was recently in the privileged position to go tiger hunting, not in “shoot ‘em dead” mode –something I could never do, but as in “capture them for posterity.” My wife, Ann, and I were in Ranthambhore National Park in Rajasthan, India, a wildlife conservation, in the hope of seeing these beautiful animals.

I got to thinking about the parallels between the conservation activities needed to save endangered species and those needed to keep our industry fit and able to meet the challenges ahead. Conservation to most people is a soft fluffy thing about tree, bunny and even tiger hugging, but the science of conservation is rigorously based on statistical models. Yes, the so-called “tree huggers” spend most of their time constructing mathematical models, based on carefully collected data, to help them understand and manage the environment scientifically.

We in DCG know that the best methods of managing software development activities revolve around metrics, strong processes, and research, and like conservationists we base our advice on those principles.

Next week, Mike Harris and I will be joined by Herbert Schmidt, our German colleague, at the Strategie Tage event in Schloss Bensberg near Cologne. Here we get to talk about providing solutions to CIOs and their colleagues. This is our second year attending this excellent conference, and since then we have added two services which we’ll be talking about next Tuesday and Wednesday: Trusted Advisor and IT-CMF.

Trusted Advisor

When Ann and I went looking for big cats at Ranthambhore, I sought advice from Andy Rouse, a wildlife photographer who had published a book on tigers. Andy told me where to stay and how to organise our game drives. Once there we put ourselves in the hands of our hosts at the Ranthambhore Bagh and our superb guide Raj, who showed us all the aspects of the park from landscape to the wonderful top predators. Asking the right people for the answer to our questions was key. In short, Andy and the folk at the Bagh and Raj became our Trusted Advisors.

At DCG we now have our own, free to join, Trusted Advisor Service. This works cooperatively – members add questions to a backlog, and every month the whole membership gets to vote for their preferred question on the list. We in DCG then remove that question from the queue and one of our consultants writes a report that is published to all in the following month. We either have the knowledge or have access to it, and members gain from the work we do, partly by seeing what concerns other members, and of course by having access to the reports we produce. We hear your concerns and, as a result, can develop our services to help you to manage them.

IT-Capability Maturity Model

IT-CMF is something I’ve been going on about a great deal. I think that it is a model with a great future, aimed at helping organisations that want to get the best value from their IT. Indeed they aim to move IT from being, at worst, a drag on the company, to being something that is a key driver for business development. Mature organisations go well beyond the cost of IT and into the value it adds to their business.

We’ve been contributing members of the IT-CMF consortium since last year, and we believe that this is a movement for the future. As companies become less focused on cost and more on how their IT is an integral part of the fully functioning business, the merits of IT-CMF will become even more obvious as users power away from the herd.

I leave you with a picture of the sublime Taj Mahal, built before IT but using the most sophisticated building methods of the day, and many trusted advisors. We think of perspective as something only understood after the renaissance, but look carefully at the square arch under the dome. Even from below it looks square and I haven’t done anything to alter the photo. The method of building this way has been known since Ancient Greek times and involves complex math and sound systems to get the best from the builders. There is not much new under the sun.

Complex problems are not new, and now, as then, trusted advisors are there to help. Come and see us in Cologne.

Alan Cameron
Managing Director, DCG Europe

So, I’m interested: where does your company sit on the spectrum below?

Mike Harris
DCG President

At a social dinner discussion this weekend, a senior level JP Morgan Chase Executive (and a friend) remarked to me how he kept a close eye on his team’s communication. If an email discussion thread started to become a long conversation with no resolution (“I’m waiting to hear back from Joe.”), he would pick up the phone and call this employee and ask, “Have you called Joe?” My friend made it clear that a phone conversation is a step above email, allowing for a more personal and direct exchange.

But, face-to-face interaction is best. That’s why I enjoyed the Quest 2012 conference so much last week – because of the opportunity to meet and connect with people face-to-face throughout the conference.

David Herron at the QUEST Welcome Reception

Pat Eglin, David Herron and myself met so many people at our booth in the EXPO hall, at our speaking sessions, and at conference-sponsored events, and it fostered great conversation!

For example, Pat spoke about Estimation at the Manager’s Workshop session. Helping people personally work through the exercises Pat designed brought out good questions about the topic, and better yet, solid interaction between those in attendance. While it can be nerve-wracking to speak to people you don’t know well, especially about business-related matters, it allows for increased participation and understanding from all those involved – and it aids in relationship building as well. I know I left Quest with some great contacts for the future, all built on personal interaction!

Email, texts, Skype and other communication tools are useful and have their place in the business world. But, to truly leverage their impact, you have to add the human element of personal interaction – not all the time, but when the time is right. Quest was a great reminder of that, and I look forward to attending next year!

Tony Timbol
Vice President, Sales and Marketing

As providers of Agile estimation services, we at DCG have noticed that while some people passionately believe Agile ownership belongs to the SCRUM teams, others vehemently argue for the Project Managers.

To settle this divisive question – and shed some light on both arguments – DCG will be holding a debate.

Agile Estimation: A Job for the SCRUM Teams or the PMO?
Register here.

Join us as we hash it out! DCG’s Tom Cagley and David Herron will be taking up either side of the argument, and two additional panelists are invited to join them.

According to Tom Cagley,

Many organizations conflate budgeting, estimating, and planning, foisting all three to groups that will not be responsible for actually doing the work under the mistaken belief that independent estimators can more accurately estimate and plan work. While this might be a good practice to triangulate on an estimate, the actual project teams, with an understanding of the velocity and productivity they can deliver, are more apt to provide predictable performance, which is why that in Agile, project estimation and planning are team tools rather than organization tools.

According to David Herron,

We all understand the importance of accountability, particularly when it comes to creating estimates and committing to project deliverables. And clearly that accountability needs to happen, in large part, at the project level. But there is a bigger picture to consider here and the role the PMO plays in the organization necessitates a shared accountability across all projects. A key point in this debate will be how an organization defines the role of their PMO and what the organization culture will actually tolerate with regard to Agile. 

Attendees of the debate will receive breakfast, as well as a discussion on how to get the most out of Agile and justify its use within an organization.

Only one side can win!

May 17, 2012; 8-9:30am EST
Valley Forge Casino Resort, 1160 First Avenue
King of Prussia, PA 19406
Cost: $15.00 (Save $5.00 if you register with the code #SocialDCG)

What do you think? Who should own Agile estimation?

Sarah Weddle
Marketing Associate / Social Media Strategist

Today, after a conversation with my colleague, Pat Eglin, about how a small start-up company might start doing business with CMMI Level 3 (or 4 or 5) in place from day one, I suddenly realized what my problem was:  If, at a basic level, lean is about eliminating process steps that don’t add value, then what, if any, parts of CMMI don’t add value?

CMMI implementations can sometimes be accused of being too “bureaucratic” or “stifling innovation,” but in my experience, these are mostly bad implementations (due to poor consultants and/or lead appraisers).  For example, I remember one of our CMMI clients in the early days of Agile telling me the maximum size in pages of the process document that he was willing to accept before we even started the analysis. Obviously not a best practice.

So, again, what parts of CMMI don’t add value?  In thinking about it now, I can see that in certain scenarios, parts of CMMI are valueless.  A trivial example is the Supplier Agreement Management (SAM) – no suppliers means no need for SAM.  The lean analysis should go deeper, but it will always be a custom analysis unique to the situation of the organization implementing CMMI in as lean a way as they can.  I expect (and hope) that most lead appraisers will recognize such an approach as being positive and maximizing the likelihood of success of the CMMI initiative.

What do you think? What parts of CMMI do not add value – if any? 

Mike Harris
DCG President

The third and final post in this series discusses how some of our clients get value from function points by considering, “What do companies use function points for?”

First, a reminder – while DCG is the largest independent provider of outsourced function point analysis (FPA) in the world, ours is a necessarily limited view of all the FPA being done in the world, and by picking only our most active clients, we have limited the view even further.

Now, to answer the question, “What do companies use function points for?,” we looked at how many applications and projects our major clients had us count in 2011.

These are long-standing clients, so the data in the chart represents a steady-state or operational perspective rather than a start-up situation.   Consequently, this data excludes function point counting work we did in 2011 as part of benchmarking and portfolio sizing exercises for new clients.  Clearly, these are common uses of function points which tend to diminish once an organization is using function points operationally.

The key lesson from the chart is that the majority of operational usage of function points (amongst these major clients of DCG) is retrospective.  That is, the function point counts are used with other data to evaluate productivity or outsourcing contract performance metrics.

Frankly, this is slightly disappointing because we believe that the best value comes from using the size information to plan, as some of our clients are doing in using the data for effort estimation and product support pricing (this involves using the size of application in an algorithm to assign maintenance costs and, hence, fix maintenance prices).  Now, my qualifier here is that I know that for many of the productivity metrics counts, our client does their own FP counts at different points in their estimation process to monitor their likely compliance with the productivity metrics they are expected to meet in their outsourcing contracts.  This use of function points by our clients does not show up in the DCG figures because the client does the estimation FP counts themselves.

What are your thoughts – what use of function points delivers most value?

Mike Harris
DCG President

The toolkit allows users to estimate project effort and schedule based on other organizations’ submitted project data. Anyone can submit data on completed projects; in fact, it is encouraged. Currently the only data collected is from DoD projects. The more actual project data submitted, the more reliable the data will become.

As a user, you enter the size range of your project in SLOC, the application domain, and the primary language, and the tool returns statistics on productivity, size, effort, and duration. The tool also generates effort distribution statistics on percent of effort spent in the phases of the SDLC. So far, it sounds good to me. 

The part I struggle with, however, is the staff’s experience distribution and the CMMI level rating distribution the tool provides. I don’t entirely understand how the data is generated based solely on the inputs I am providing. Since the CMMI model is not dependent on the size method or development language I use, I find it difficult to determine how the tool is able to generate a level, and more importantly, how reliable that statistic is.

I think this tool is definitely one to keep an eye on, and I am interested in seeing where it goes following feedback on the beta version. I think it will take some time to see if the statistics generated are truly valuable when estimating new projects. If it is, it may revolutionize the estimation of projects. And, we all know that estimation is one area most organizations are looking to improve!

You can check out the tool yourself at http://www.thedacs.com/databases/SSCPAT, but note that you will need a log-in to do so!

What do you think? Will this tool revolutionize estimation?

Patricia Eglin
Process Improvement/Measurement Specialist, Certified Introduction to CMMI Instructor and Six Sigma Green Belt

First of all, I want to thank the organizers and participants for making this one of the most lively and enjoyable conferences that I have attended in some time.  Just about every session I attended involved a level of dialogue between presenters and participants that was livelier than I have seen in some time and considerably more positive in the sense that the participants were practitioners who were keen to learn and keen to help. Kudos!

So, what were my main takeaways?

•  Nobody has much faith in ROI as a justification for projects because very few organizations track actuals.
• Chargeback of IT to business units is ubiquitous, but the methods used and assumptions made can vary considerably. It would seem that some form of standardization of methods or at least options would simplify the implementations, auditing and benchmarking.
• As for chargeback, so goes capitalization of application development. Here there are reasonably strong accounting guidelines and best practice seems to be to link capitalization to specific timesheet tasks. The differences between organizations seem to be based on how comfortable they are in moving into the gray areas of the accounting definitions. Capitalization of Agile Development (or more accurately justifying it to a subsequent audit) is one of these gray areas where the ITFMA community seem to be a few years behind where the developers are with agile adoption.
• Probably about 10% of the audience for my IT-CMF presentation knew what IT-CMF was before the conference.

My presentation on IT-CMF is available here. You can also check out our Facebook and Twitter pages for photos and additional thoughts on the conference!

Mike Harris
DCG President

I know that I’m personally excited to be presenting and also to have the opportunity to listen to some excellent speakers discussing a wide array of topics. I always leave a QAI conference more informed and richer for the experience. It was particularly rewarding for me to have my article in the program brochure as one of the featured articles this year!

I will be presenting on Wednesday, May 2 from 9:45-10:45am. My topic, Identifying Your Organization’s Best Software Practices, should be an exciting discussion with a bit of controversy thrown in for good measure.  I intend to challenge conventional wisdom by questioning some of today’s methods and techniques labeled as ‘best software practices.’ Who is to say whether or not something is a best practice? And how do you know it will be a best practice in your organization? It should be a fun discussion and I am hoping for some good participant interaction.

I will also be available at the David Consulting Group booth in the exhibition hall. Stop by booth #19 and say hi – you’ll recognize me from my photo above!

What are you looking forward to about QAI Quest?

David Herron
VP Knowledge Solution Services

Today, I want to talk a little about the scale of some of clients’ use of functions points by considering, “How extensively do companies use function points?”

First, a reminder – while DCG is the largest independent provider of outsourced function point analysis (FPA) in the world, ours is a necessarily limited view of all the FPA being done in the world, and by picking only our most active clients, we have limited the view even further.

Now, to answer the question, “How extensively do companies use function points?” we looked at how many applications and projects our major clients had us count in 2011.

Function Point Counts for a selection of DCG Clients 2011

These are long-standing clients, so the data in the chart represents a steady-state or operational perspective rather than a start-up situation. So, as expected, we see relatively limited counting of new applications. Indeed, the average size of the applications counted is an indicator that, for those companies, “applications” are defined to be any standalone functionality.

The key lesson from the chart is that there is wide variation in how extensively companies use function point analysis (FPA); although, to be fair, this may simply be a reflection of how much they use DCG for FPA!  Perhaps a broad conclusion is that about half of the companies in our survey use FPA for less than 20 projects per month (240 in 2011) and half use FPA for more than 20 projects per month.

Something else of notice is the variation in the average size of projects from one client to another. If projects from all clients were broadly the same average size – not an unreasonable expectation with this respectably large sample – then all of the “project” points would lie on or close to the same line. That is far from true, which suggests that there may be something about the functionality in software projects that is industry-dependent.  Remember that the use of function points for sizing removes any project size dependencies on platforms or programming languages or effort.

What are your thoughts – how extensively do you think companies use function points?

Mike Harris
DCG President