I have been enjoying Alan Cohen's A Deep Breath of Life. I read it every morning with pen in hand, never failing to find at least one or two profound sentences to be my watch-words for the day. One of the July writings contains this quote: "Only infinite patience begets immediate results."  David writes about the perils of rushing through life, and how a lack of patience can causes us to create unnecessary chaos in our daily rounds. He writes, "Rushing never improves the quality of our life or the results we seek; to the contrary, it muddles our vision and causes us to make errors that cost us twice as much time and energy to repair."

One of my first thoughts was about my work at QSM, and how SLIM-Estimate demonstrates the power of patience in software development. Is it possible to exercise patience when there are important business objectives and profit margins to achieve? The Putnam software production equation, backed by 30 years of industry data, shows that relaxing the project schedule gives the best “bang for your buck” to produce value for your customers.

QSM is pleased to welcome J. D. Ottenbreit and James Heires, two recognized industry experts, to our growing professional services team.

An accomplished business leader with 15+ years of technical and functional experience that spans the commercial, government and academic sectors, J. D. Ottenbreit specializes in client and large account management, project/program oversight and control, the full software development lifecycle, quality assurance, business process redesign, as well as strategic planning and execution. He has led teams both domestically and internationally as part of a former Big Four corporation, a Fortune 50 company, and as an advisor to various cabinet level government agencies and departments.   

Jeff will lead the QSM commercial consulting line of business where he and his team leverage our SLIM Suite of Tools and deep business insights to provide software modeling, project stewardship and best practice, metric and benchmark studies for application development and IT decision makers. 

Jeff is a certified Project Management Professional (PMP) and trained in the Information Technology Infrastructure Library (ITIL) methodology and Carnegie Mellon’s Software Engineering Institute’s Capability Maturity Model Integration (CMMI) model. He holds a MBA in Management Information Systems from Sacred Heart University, a Bachelor of Arts from the University of Saskatchewan, and is a graduate of the Yale School of Management Strategic Leadership Workshop. 

In spite of 30 years of structured programming, CASE tools, OO development, 4th GL languages, CMMI, and PMI, the failure rate for larger projects has failed to respond to all of this love and attention. We normally think of failure as a negative thing; but it can have its upside. Saddling a competitor or enemy with a doomed project could stain their career or at the very least inflict a high level of pain on them. A CEO about to retire, or whose focus is on near term stock options, may be able to boost quarterly profits by continuing to add staff to a doomed effort:  one for which the customer pays for the added staff, of course.

Since failure is a constant, here is a management guide on how to assure failure. While any one step in the process can be overcome, taken together they create the perfect software project storm.

Step 1: Start work as soon as you can

Come on. You don’t really need to spend all that time in requirements meetings and documenting assumptions. Real projects take the ball and run.  Be sure to begin coding as quickly as possible. Call it prototyping if you will; but do get started. You can always circle back to tweak things if needed.

Step 2: Estimation is overhead

Nothing is more frustrating and time wasting as having to go to some external group who know nothing about your project and have them tell you how long your project should take, how many people should be on it, and what the trade-offs are. What can their mathematical models possibly know about your project? A good end run around this situation is to create a project plan and call it your estimate. Make sure that it is very detailed and contains decimal points, since these will make it more difficult to challenge.

Thomas C. Redman recently wrote about data quality on the Harvard Business Review blog.  In his post, he creates a vignette of an executive who finds an error in data provided by the "Widgets Department" for an important meeting. The executive corrects the error, the meeting is a huge success, and the story ends there. Redman argues that someone should have gone back to the Widgets Department to report the error, not to complain that the error could have ruined the presentation, but rather that it could ruin the next person's presentation.

The hardest part about database validation is not reviewing every individual project, but rather, determining if the information on each tab is correct. Sometimes, it's easy to tell that the organization name is spelled incorrectly, other times, it's difficult to discern if a labor rate is incorrect. Having a well-documented database is important, not just for your own use, but for whatever you plan on using it for next.  For example, if you plan on making custom trend lines, but you recorded that it took you 31 man months instead of 3.1 man months, that would have a disastrous effect on your trends! It's obvious that the error would need to be recorded, but it's also important to report the error to whoever prepared the data so that they can check the rest of the projects in the database for the same error. 

Redman suggests creating an office culture which promotes the following three points:

David McCandless gave a TED talk  in July 2010 that focused on pairing data and design to help visualize patterns.  In his talk, McCandless takes subsets of data (Facebook status updates, spending, global media panic, etc.) and creates diagrams which expose interesting patterns and trends that you wouldn't think would exist.  Although the focus of McCandless' talk was about how to effectively use design to present complex information in a simple way, I was struck by his own claim that data is not the new oil, but rather that data is the new soil.  For QSM, this is certainly true!

QSM maintains a database of over 10,000 projects with which we are able to grow a jungle of ideas, from trend lines to queries about which programming languages result in the highest PIs.  With  the amount of soil that we have, we are able to provide insight into the world of software, just with the data that is graciously provided by our clients.  By collecting your own historical data in SLIM-DataManager, you can create your own trend lines in SLIM-Metrics to use in SLIM-Estimate and SLIM-Control, analyze your own data in SLIM-Metrics, tune your defect category percentages and calculate your own PI based on experience in SLIM-Estimate, and much, much more. 

If you were unable to attend our recent webinar, Using Function Points and SLIM to Support a Complete Estimation Process, a replay is now available.

How can project managers use their Function Point history to improve the way they estimate their projects? Leveraging historical data to generate and sanity check macro-level estimates early in the project lifecycle can save thousands of dollars in planning time and prevent signing up to unrealistic project schedules and budgets. Now that we've learned the basics of estimating before requirements, Keith Ciocco demonstrates how to use industry data and Function Point history with the SLIM Suite of Tools for a more mature estimation process. 

As Vice President of QSM, Keith has more than 25 years of experience working in sales and customer service, with 17 of those years spent at QSM. Keith’s primary responsibilities include managing business development, existing client relations, customer retention and response. 

Watch the webinar replay!

The thirty years I have spent in software have bridged a period of remarkable and ever accelerating change. Mercifully, coding an online system on a black and white CRT that accesses an IMS database is mostly a quaint memory. Technology, tools, and processes have all evolved. Why is it, then, that we continue to have the same problems we experienced in the Information Technology Dark Ages? Here are the symptoms:

• Software projects that continue to overshoot their schedules
• Quality problems have neither disappeared nor lessened to an acceptable level
• Budgets are regularly exceeded: sometimes wildly
• Project estimates are inaccurate

I see two principal reasons. I’m certain there are others.

Our Focus on Technology

We are not Luddites resisting change; we love technology and embrace it whole heartedly. We have a rich array of programming and testing tools at our disposal. Why, then, have problems with cost, schedule, and quality persisted?  

One reason is that we focus on technical solutions to problems with many non-technical components. Suppose you have the choice of coding a project in COBOL or Visual Basic. (Suspend your disbelief for a moment and accept that both languages are suitable for the task at hand.) You will produce far less code in VB than in COBOL. You may see some slight reduction in cost and schedule; but it will not approach the 40 – 50% reduction in code that will be seen if you choose VB over COBOL.  

The reason is fairly simple. On a project of any size, coding and unit testing is not where most effort is expended. One number that is touted puts coding/unit testing at 30% of total project effort. This means that a 50% reduction in coding effort yields only a 15% reduction in project effort. While we want and need more effective tools for coding and testing, they have little impact on the remaining 70% of project effort.  

On Thursday, June 28 at 1:00 PM EDT, QSM's Keith Ciocco will present Using Function Points and SLIM to Support a Complete Estimation Process.

How can project managers use their Function Point history to improve the way they estimate their projects? Leveraging historical data to generate and sanity check macro-level estimates early in the project lifecycle can save thousands of dollars in planning time and prevent signing up to unrealistic project schedules and budgets. Now that we've learned the basics of estimating before requirements, Keith Ciocco demonstrates how to use industry data and Function Point history with the SLIM Suite of Tools for a more mature estimation process. 

As Vice President of QSM, Keith has more than 25 years of experience working in sales and customer service, with 17 of those years spent at QSM. Keith’s primary responsibilities include managing business development, existing client relations, customer retention and response. 

Watch the replay of this webinar!

After one particularly difficult midterm in college, my professor said, "This is just a wakeup call; there's still time to improve before the final." I think that wakeup call was particularly painful, but my professor's words stick with me today, especially when thinking about data collection (or lack thereof) when a project is over.

As someone who is not a project manager, it was difficult for me to understand why project managers would not collect their own historical data. I understand now that after a project is finished, people move on to the next project and there's no time to update project stats. Recently, I read a post on Gantthead.com by Kenneth Darter called, Project Closure: Party or Post-Mortem?. Darter says if the project was a success, then it's important to record why it was successful; if the project was not successful, it's important to capture why it was not successful.

The word "data" in Latin literally means "things having been given." At the end of a project, you have been given a lot of things that only you and your team know: size, effort, duration, staffing, PI, cost, etc. If you are able to take a moment to fully document your project information, you not only build a historical database, but you're able to reflect back on that project to improve future endeavors (whether you would like to remember it or forget it completely). Darter recommends creating a checklist which, "should be defined early on in the project and communicated to everyone who will have input into the checklist at the end of the project." In addition to project specific information, he specifically recommends these three items:

Our recent webinar, Estimating Before Requirements with Function Points and Other Metrics, was a huge success! If you were unable to attend, a replay and pdf version of the slides are now available. If you have any questions regarding this material or QSM's Function Point Analysis services, please do not hesitate to contact us.

It is well known that project estimating based on parametric models has reached a sophistication where realistic estimates, schedules and predictable outcomes are indeed possible given a set of software and systems requirements. However, increasingly with the fast pace of Agile and other development methods is the requirement for estimates much earlier in the life cycle. What happens when project estimating moves back a full phase – before requirements, and acquisition managers, contractors, auditors and financial analysts are forced to develop and analyze estimates based on unknown requirements? Presented by industry expert Carol Dekkers, this presentation examines how to identify and document assumptions, create a logical and traceable project map including locations of potential “landmines” (calculated risks) that accompany this preliminary estimating. Experienced estimating professionals and contract managers will find a basis for common ground in this presentation – as the advice presented will create the basis for dialog and discussion of early estimates.

Watch the full replay here!