Category Archives: Uncategorized

Culture Clashes at Work – Fact or Fiction?

I come across a ton of articles about workplace dynamics and how the current rate of unhappiness at work hovers around 70%!

70% – wow!  This means that almost 3 out of 4 workers spend a huge portion of their waking hours, dissatisfied.  Put another way, if you happen to be in the 30%, you’re surrounded by unhappy colleagues.  If you’re in the 70%, it’s a miserable place to be.

unhappyWhat is the source of such massive discontent at work?

According to Inc. magazine, (Dec 2017) there are 10 Science-Backed Reasons You’re Unhappy at Work

  • Your boss. One huge reason for unhappiness at work is your boss. …
  • Your co-workers. We are surrounded by others in our office all day long. …
  • The type of work you are doing. Many do not enjoy the type of work they are doing.
  • Your attitude. …
  • The commute. …
  • Stagnant growth. …
  • Lack of appreciation. …
  • Overworking.
  • Jealousy of your friends.
  • What your company stands for.

As agile practitioners, measurement specialists and IT people (my readers) – I wonder if there is isn’t also a Culture Clash – constantly having to answer questions and explain why we do what we do (5W’s and How about technology) – that contributes to discontent.

I believe that (in most companies), we have a minimum of three distinct cultures at work – (each with its own language, set of goals, and behavioral norms):

  • Business
  • IT (and technology pros)
  • Marketing
  • Finance
  • etc.

Geert Hofstede (Software of the Mind, circa 1980’s) developed a model of Cultural Dimensions that delineated National (country specific) Culture in 5 dimensions:

Image result for cultural dimensions

I believe a similar construct could be made to delineate the differences between Workplace Cultures.  We walk around all day speaking the same physical language (English in the US) – yet our work languages are vastly different.


Similar to how countries (and states within many countries) are unique, workplace cultures present unique cultural challenges/opportunities.

What do you think?  Is it research worth pursuing?

I’d love to hear your comments… Carol


Bias: It’s like Kryptonite to Collaboration

Collaborate: the concept is so ingrained with agile development that it’s one of the four components of Alistair Cockburn’s simplified Heart of Agile approach (along with Deliver, Reflect and Improve.)  Yet, collaboration has an “achilles heel”, a Kryptonite of sorts, that no one really talks about:  Bias.

Before we get into the roots of Bias and its effects, let’s explore what’s at the core of Collaboration.


To collaborate (according to Google Dictionary) is to

cooperate, join (up), join forces, team up, get together, come together, band together, work together, work jointly, participate, unite, combine, merge, link, ally, associate, amalgamate, integrate, form an alliance, pool resources, club together,  fraternize, conspire, collude, cooperate, consort, sympathize…

Collaboration relies on a combination of team skills: listening, communicating, connecting, cooperating, observing, and setting aside personal agendas and opinion.

Bias is like Kryptonite to Collaboration

Bias creeps in innocuously while we’re truly practicing our good communication skills; it can coat our words and can jade our thought process without us even being aware of it.  At best, bias skews our creativity, at worst, it kills trust and collaboration.

While we may not perceive bias in ourselves or others (“after all, we’re open and honest professionals doing our best”) – it’s there.

The good news is that Bias is like the iceberg below the surface that we didn’t know was there, and once we’re aware its there, we can dismantle its effects.

Through conscious practice and exercises, our awareness of our own biases can increase and we can override its effects.

Types of Bias

Bias comes in a variety of flavors and styles – and, we all have it in one way or another. The first step to overcoming bias is to recognize and acknowledge it in ourselves.

What kind of bias(es) do you hold?  I’ve condensed the list of bias types (from data analytics and psychology sites) and added examples for agile projects:

  1. Confirmation Bias – We skew our observation of an event, concept, person in a way that confirms our already held belief.  A pattern of highlighting news that agrees with the agenda of the left or right, and ignoring the other side.
    Example:  Changes are needed to a delivered report because legislation changed (fact), and we think “Typical of the users always changing their minds” (confirms our belief.)
  2. Attribution Bias – We attribute an action to someone based on their personality (flaws) rather than the situation.
    Example:  The project is delayed because testing isn’t finished.  We think:  “the tester doesn’t know what they are doing” (attributing it to a personality flaw) rather than looking at the situation of tester work overload.
  3. Commitment Bias – Continuing to invest in a derailed project because of the sunk costs already committed (time/effort/money.)
    Example: We think: How can we bail on this project after we’ve already spent a year and $500K on it?
  4. Labeling Bias – We (un)consciously describe or label a person/group in a way that influences how we think about them.
    Example:  We think marketing (people) have no clue about technology (so why ask them for input)?
  5. Spin Bias – We accept only one interpretation (ours) of an event or policy to the exclusion of the other.
    Example:  We spin the news (especially when there is a gap):  China banned cryptocurrencies, so it must be because of… (nefarious financial dealings…)
  6. Spurious Correlation Bias – We believe causality (without checking) between two potentially (un)related events or circumstances.
    Example:  Gas prices always go up before a long weekend.
  7. Omission Bias – Leaving out important information/people (certain facts or details) on a project because we don’t see its relevance.
    Example:  We didn’t think of including IT folks in a renovation project meetings (we omitted the importance of moving the network…)
  8. Not like Me Bias – Dismissing information or ideas because of the source or group generating it.
    Example:  We think that new hires have no idea about how our company works (when their input may be fresh and show us new ways to work.)

When we allow these unconscious biases to influence how we send or receive information, we stymie true collaboration.

What biases do you see in yourself and your workplace?  When I, personally realize I have a particular bias, I make a conscious effort to pause before responding.  When I’m prone to say something that would block collaboration (words like “we can’t do that…” or even the seemingly innocent thought in my head like “what on earth?” I try to stop and ask myself why I would think that.  Pausing to reflect and see the part that my unconscious bias plays, really helps me to collaborate better.  Might it work for you?

Would you Play Along?

Over the coming weeks, please join me in a new blog series called “The 5% Social Experiment” where I’ll post some easy social experiments to identify and overcome workplace bias.

Can I count on you to play along?


Chicken and Egg and Agile: What comes first Hard or Soft skills?

How would YOU answer this question?

Stereotypically people answer based on their experience and expertise:  

  • technical pros choose hard skills first (programming, math, logistics, complex problem solving,) because they involve complexity and are quantifiable. Soft skills are seen as qualitative (less value) and simpler (aka “fluff”) and easier to learn on the job;    
  • business people choose soft skills first (communication, emotional intelligence, listening, time management, collaboration) because it can be impossible to work with people who lack them. Technical skills, they reason, are easier to learn. 

Ultimately, we need a combination.  The most successful agile teams possess a combination of both skills: clear communication, understanding, empathy, time management, collaboration AND technical competency.

Oft cited research states that 85% of job success comes from having well-developed soft skills (people skills) and 15% is a result of technical skills and knowledge.  Software development used to be an anomaly to this, but no more.

A Look at SD History 

A mere 30 years ago, engineers and computer scientists owned software development: programming was a specialized skill that afforded coders both job security and relative seclusion.  In the beginning, before SDLC (software development life cycle) methodologies, users wrote out bits of requirements and passed them over (“the wall”) to programmers who turned them into computer programs using “code and fix.”  Interactions between the business and IT (information technology) were isolated, formal, and controlled. 

I remember colleagues 25 years ago lamenting that “software development would be so much easier if we didn’t have to deal with users.”

Fast forward to today’s agile environment where communication, collaboration and frequent software deployment are norms.  Co-located open space team areas replace rows of stoic IBM coders working in isolation and according to a recent Career Builder study: 77% of employers now believe that soft skills are equally as important as “hard” or “technical” skills in the work environment. 

Yet… technical professionals go into their professions for the same reasons they always did: to solve complex problems based on math and science.

The Value of Soft Skills

Reading stories of agile transformation success leads one to think that every workplace is like Google:  teams of co-workers celebrating each other’s differences, playing games at work, seeking to maximize their collaboration – the perfect combination of soft and hard skills. 

In 2013, Google decided to test its hiring hypothesis by analyzing 15 years’ worth of hiring, firing, and promotion data.

This project led to the surprising discovery that hard skills come in last among the top seven qualities of Google’s top employees.

“The top 7 characteristics of a successful Google employee are in fact:

  1. Being a good coach
  2. Communicating and listening well
  3. Possessing insights into others (including others different values and points of view)
  4. Having empathy toward and being supportive of one’s colleagues
  5. Being a good critical thinker and problem solver
  6. Being able to make connections across complex ideas
  7. STEM expertise

If nearly all of the top characteristics of success at Google are soft skills, then there is a strong argument for investment in those skills being not just a sound investment, but a vital one.”

Can soft skills be learned?

The jury is out on this – some say yes (emotional intelligence, awareness, communications classes) while others profess that soft skills are personality based.  

What is YOUR experience – do you think soft skills can be learned? 

Have we reached the Shangri-la in software development with agile?  

How would you answer this post: What comes first in agile – soft skills or hard skills?

Thank you in advance for your comments.


Reprise: Software Cost Estimating, If You Don’t Know What, You Can’t Estimate How… and ICEAA TAMPA

I first published the article listed below in 2014 – A WHOLE 5 years ago, and as I prepare to present at next week’s ICEAA (International Cost Estimation and Analysis Association) Professional Development and Training workshop (conference)next week in Tampa, I realize just how important a topic it was (and is today!)

Comments welcome!  Here’s the original blog post reposted for your enjoyment:


One of the biggest (and not so obvious) reasons that software estimation goes awry is that amateur estimators don’t always realize how important it is to figure out the “object of estimation” – that is, what it is that we want to estimate. 

I’ve addressed this issue on several occasions – through a set of 4 blog posts called “First see the elephant in the room (the what you are estimating…)”

This week, I did a blog post for QSM, Inc. on the same topic.  Let me know what you think.

21 if you dont know the what

Opinion: Soft skills Leverage Value on Agile Projects

“Potential is all of the resources you have in front of you. Efficiency is putting those resources to use effectively.” — Garrett Gunderson

I hear all the time that we live in interesting times (meaning challenging, regressive/progressive – depending on how you view the world) – but I believe every time is an interesting time.  In software development, the above quote seems especially apt for our times considering that the pace of technology (Moore’s law) continues to accelerate, AI is beckoning at our door with self-driving cars and robotics, and the race to be first in anything and everything (a US stronghold) appears to dominate our workplaces.

In our pursuit of good/better/best solutions, I believe that the technical teams often overlook the gains that could be gained from clear communication and cross-cultural team collaboration. In other words, the value of soft skills (meaning acceptance, emotional intelligence, honesty, embracing differences) are often overlooked in favor of technological advances.

One of the biggest elephants in the room (in my humble opinion) is the fact that technical professionals (programmers, systems analysts, scrum masters) are much more well versed in the hard, technical skills than they are in the soft, people skills.  The barrier or crevasse between different types of people (for example marketing and IT professionals) remains one of the biggest, unspoken gaps in software development.

I already anticipate the responses – Agile HAS increased overall collaboration and cross team/discipline understanding, but the basic human diversity remains an issue.

To check your soft skills or collaboration level with your team (all members of your co-located or geographically dispersed team) – take a look at this checklist.  If you cannot answer at least 2 of these questions for each team member, then the communication and true collaboration could use some work:

  • Do you know what order your team members would prioritize the following values: Honesty, directness, kindness, punctuality, teamwork?
  • What is one activity that each team member looks forward to doing on the weekend?
  • What kind of pets do your team members have?
  • What is the favorite food of your team members?
  • Where did your team members go for vacation in the past 18 months?

You might say that these things are invasive, personal details that don’t belong in workplace conversation. And, depending on your company, the culture might allow or prevent such disclosures.

I present these as a few questions to consider – and food for thought for advancing collaboration.  What do you think?

Are soft skills overlooked on your team?

The Heart of Agile – Simplifying the State of the Art

I’ve been an absentee blogger here for the past several months (yikes, has it been almost a year – time flies at my age!!!)

BUT… I’ve not been sunning myself on the slopes of Austria or lying at the beach (while I do live close to one!) – I’ve been busy with project management training, software measurement consulting, leadership development (for new courseware) and, most exciting to me, becoming involved with Dr. Alistair Cockburn’s HEART OF AGILE community.

I’ve joined an illustrious and creative team of international knowledge experts from around the world. Our common goal is to share and gain insights from real-world agile successes and simplify the sometimes complex world of agile development (beyond software development) into the four major concepts of the Heart of Agile (HOA or HoA):

  • Collaboration
  • Delivery
  • Reflection
  • Improvement

The concept of the Heart of Agile is innovative, refreshing, human and heart centered and it works wonders.  More to come in a plethora of posts (making up for lost time!)

Meanwhile, take a look at the website and let me know what you think!

To future MusingsAboutSoftwareDevelopment!

p.s. It’s good to be back in the writing mode. I’ve got so much to share with you!


Unit Pricing and Scope Management — New concepts for Agile projects?

The Agile Manifesto spawned a revolution in software development almost 20 years ago and continues to change a generation of product developers.  From the humble beginnings of 17 software development disrupters penning a manifesto in Park City UT to today’s scaled agile frameworks and a myriad of prescriptive methods, agile has taken over center stage from yesterday’s “waterfall” development approaches.

As with any cultural change (I’d argue that true agile is a culture), there’s been clashes of old school thinking and new school progressiveness…

Old school “staples” for software development included estimating, budgeting, on-time and on-budget project tracking, EVM, scope management, and measurement.  Not only do some of these concepts strike panic in agile developers, some have even sparked new “anti-”  movements (e.g., #noestimates.)  More than once I’ve heard developers refer to  “old school bean counters” and “out of touch C suite execs” when the words estimates or budgets are mentioned.

Yet as much as some agile creatives like to assert that estimates are futile (how can one estimate creativity?) and early failures are critical to innovation (it can take 3000 ideas to deliver the right one) – corporate America still runs on dollars and days (budgets and schedules.)

One way forward that has proven successful that satisfies the needs of executives (who want to know progress and early ROI) and also project teams (who are challenged to measure delivered business value) is called “Unit pricing.”

Here’s the approach:

Step 1:  Revisit completed projects:  Evaluate and measure past completed product releases:  delivered software product size, team effort (person hours) to deliver the release, estimated rework (%), number of sprints, team size, cost.

Having such a historical basis for unit pricing is useful, however, publicly available databases such as the Development and Enhancement project repository (International Software Benchmarking Standards Group – ISBSG) can suffice if you don’t have your own historical data.

Step 2: Generate a high level “budget” for your new product delivery (release or project), by first guesstimating a “relative” size (ballpark) for how big could be the software. Some companies use a rudimentary t-shirt sizing scheme (xs, small, medium, large, xl, xxl, etc.) as a comparator.

This estimated size will be wrong from the get-go, but selecting a “ballpark size” gives you an upper limit of software size to guide the project.  The overall budget is derived by taking your best guess of the size (in function points) and the applicable unit price in $/FP (as derived from the actual costs of similar past projects.)

Management will then approve the project (or release) based on this “guesstimated” size and budget, and the project begins.  (Budget $ / size in function points provides an initial agreed upon rate of $/FP. This can be used as a payment mechanism and/or a gauge of project progress.)

Step 3:  Given the “bucket” of project money and an assumed, not to exceed (maximum) product size, you’ve got the unit pricing that you’ll use when bits of software are delivered.

Step 4:  The scope of the project is the product backlog as defined by the product owner /customer.  (Note that the size of the product backlog is unknown at this point, however, as user stories are completed, they will be sized and recorded along with the sprint they were part of.  At the end of the project, the size of the completed user stories will be known.)

Step 5:  As bits of software are delivered, they are sized (in FP.) The cost is calculated as the budgeted unit pricing * FP) – and both the size and cost are recorded for the delivery.  Costs are tallied and subtracted from the original budget.  If a product backlog item is returned to the backlog at the end of a sprint (partial completion), there is no measurement of its size or cost.

Step 6:  During the project, the team gets to focus on product development and delivery rather than estimates.  However, at any point in time, team members and executives can get a glimpse of where the project is at by looking at the delivery sizes and costs to date, and gauge how muchprogress is being made.  Creating product burndown charts (costs expended to date out of the original budget amount) and depicting the growing product size can be done quickly and easily.

The agile teams stay focused on being creative and developing product.  At the same time, executives have their progress reporting (delivered size, budget spent to date, remaining budget.) This is a modified approach that follows concepts outlined in the Finnish Software Measurement Association (FiSMA) northernSCOPE method (

What do you think? Would unit pricing and progress tracking be a way forward for your agile projects?

Comments, brickbats (an old school word for criticism), ideas welcome.


GDPR, Forget Me and Human Connection

Last week, the first of many sweeping data privacy laws went into effect in Europe:  The General Data Protection Regulation or GDPR.  If you’ve ever traveled abroad or given your email address to a company that does business in Europe, you’re likely to be peripherally familiar with the legislation that has far-reaching implications globally and regulates what types of identifying data that companies can keep about you.  Without going in to detail, (a reasonable read on the subject is found at among others,)  people must explicitly renew and opt-in to continue to receive emails from corporations and services. Companies have spent hundreds and thousands of hours pulling together new policies about how they store and keep data about customers/subscribers.

Individuals under GDPR can also ask to “Be Forgotten” – to which corporations must remove ALL DATA EVER STORED ABOUT AN INDIVIDUAL (including previous names, email addresses, and other data.)  GDPR will change how the world at large views and saves personal data, and, that’s a good thing.

This falls on the heels of the latest issues with Facebook and Data Privacy Breaches where Mark Zuckerberg faced the US Congress, and later  revised their privacy practices (which, hopefully will cause other social media sites to also change.)

With the rise of identity theft and other wrongdoing based on negligent (and sometimes fraudulent) handling of personal data, these new requirements are good provisions. Corporations and their officers should be safeguarding the data they collect at our expense or face financial penalties for non-compliance. It’s going to be interesting to watch in the coming months as lawsuits start to amass… just speculating.

Sidenote: On a related topic, the regulations don’t help to allay the fear about what ‘Big Brother’ (government and corporations) do with the video and audio they collect on me (and everyone else) as we go about our everyday lives.

Am I the only one who finds it a little too intrusive when Google asks me “Have you recently been to Starbucks on xxx St ?” and then asks me to rate the experience to help out other visitors? (Note to self: turn off the Location setting on my cell phone.)

is keeping in touch out of vogue – can we reconnect?

Personally, I think it is disconcerting to see how disconnected we truly are today — despite the seemingly increased digital connectivity of social (and other) media.

Over the past 30 years as a consultant and speaker, I’ve met tens of thousands of people whose email addresses are scattered across various pieces of hardware (some long obsolete!)  I have so many fond memories of people I’ve met and places I’ve traveled; the stories and snippets of life we’ve shared (part of what makes conferences and consulting so worthwhile!)

I wonder about the people I’ve met and lost touch with (maybe even you!) and regardless of whether we shared a moment or a month, there was a connection.  I recall warm handshakes at the end of a presentation, smiles and shared conversations over coffee and dinners, solving problems with strangers (with corporate challenges,) and, of course, the goodbyes at the end of a class or a contract.  (Yes, I love my work!)

Every email address in my databases equals at least one human being with whom I’ve crossed paths with, and most likely lost touch. I wonder about your news and your kids and your experiences since we last met (or correspondence or chatted) – and, if you’re interested, I’d love to reconnect.

I’ll go first (to give an update):  I’m still actively presenting new ideas about measurement, agile, and leadership at conferences, still consulting and teaching workshops on function points (the square foot measure of software size) in new environments (especially agile!), as well as developing new courses to enrich corporate health through leadership, project management and metrics.  I’m passionate about cultural diversity (Hofstede and Trompenaars), the Heart of Agile (thank you Allistair Cockburn!), EI (emotional intelligence) and transforming our workplaces/workforces to be inclusive of people, technology, and fresh ideas.

I’m still the same energetic, optimistic, curious female engineer and consultant you met somewhere on some occasion, and as with every consultant, I’m always open to new / renewed client engagements where I can help you to streamline your operations (with great leadership and Project Management initiatives) and add measurement to demonstrate your department’s value! (I hope you’re okay with this shameless plug, I am taking on new clients at this time. Call or email me…)

Forget me….

On the opposite side, the Forget Me concept is interesting… considering the high percentage of flawed and incorrect data stored about all of us.  (Case in point – have you ever done a vanity search of your name in Google and found your name associated with the current address of exes and family members at locations where you’ve never lived?  Or done a public records search where identity results show records of invalid and incorrect data?  Data are gathered from disparate and diverse public and private databases – with little data validation.)  I wonder how corporations will actually be able to guarantee data removal when so much of the stored information is flawed.

Compounding the situation are purposely errant data (mis-entered by applicants who mistype their email address or falsify identifying information to avoid later spam, when registering on a site) – I’m curious how companies will be able to make sure that all data are removed on request. “Forget me” – what an interesting concept in a world that wants to be appropriately connected.

It’s probably time for a full EMAIL dataBASE refresh

I read a perspective piece in this past Sunday’s Tampa Bay Times newspaper “One man is updating his own privacy policy” by Konstantin Kakaes – it was an  interesting article that opened with

“Dear everybody who has sent me an email since  April 23, 2004, the day I got a Gmail account…”

The three column, half page piece addressed every type of email communication (from family to friends to generic spam to subscriptions to group lists,) 13 different groups in all, and outlined how he plans (tongue-in-cheek) to use the various pieces of data he’s retained on his various laptop incarnations and storage devices.  An interesting approach to cleaning out (or at least contacting) everyone in his email database.

P.s., watch this space for news about an exciting Powerful Presentations and Corporate Engagement workshop (I’m developing it now) – set to launch in the autumn of 2018.  Interested in knowing more (we’re targeting Sept in Napa Valley, CA!) – drop me a quick note!

Blogging is the ultimate “broken telephone” so, if you’ve read this far, do me a favor and shoot me a quick email ( or drop a comment and let me know that you’re out there…  

p.s. Is anyone there?  Did this post resonate with you? Was it too long/just right/boring/fun?  LMK (Let me know…)

Quality Assurance Assn of MD – Register Now: “How to Identify and Mitigate Software Security Risks and Vulnerabilities” on May 15, 2018 in Columbia, MD – Earn 3 PDU’s for only $35 for attending.

Topic: How to Identify and Mitigate Software Security Risks and Vulnerabilities.

 Presenter:        Joe Jarzombek, PMP, CSSLP

Date:                     May 15, 2018


As the cyber threat landscape evolves and external dependencies grow more complex, managing risk in the Internet of Things (IoT) supply chain must focus on the entire lifecycle.  IoT is contributing to a massive proliferation of a variety of types of software-reliant, connected devices throughout critical infrastructure sectors.  With IoT increasingly dependent upon third-party software of unknown provenance and pedigree, software composition analysis and other forms of testing are needed to determine ‘fitness for use’ and trustworthiness. Application vulnerability management should leverage automated means for detecting weaknesses, vulnerabilities, and exploits.

Addressing supply chain dependencies enables enterprises to harden their attack surface by: comprehensively identifying exploit targets; understanding how assets are attacked and providing more responsive mitigation.  Security automation tools and services, and testing and certification programs now provide means upon which organizations can use to reduce risk exposures attributable to exploitable software in IoT devices.

Attendees will Learn:

  • How external dependencies create risks throughout in IoT/software supply chain;
  • How software composition, static code analysis, fuzzing, and other forms of testing can be used to determine weaknesses and vulnerabilities that represent vectors for attack and exploitation;
  • How testing can support procurement and enterprise risk management to reduce risk exposures   attributable to exploitable software in IoT devices.

Please Note:  Attendees receive PDUs or CPE’s to use for recertification credits at PMI, QAI, ASQ, ISC2, ISACA, IEEE or ISTQB, etc.

 Speaker Biography:  Joe Jarzombek is Director for Government, Aerospace & Defense Programs in Synopsys, Inc., the Silicon to Software™ partner for innovative organizations developing electronic products and software applications.  He guides efforts to focus Synopsys’ global leadership in electronic design automation (EDA), semiconductor IP, and software security and quality solutions in addressing technology challenges of the public sector and aerospace and defense communities.   He participates in relevant consortia, public-private collaboration groups, standards groups, and academic R&D projects to assist in accelerating technology adoption.

Previously, Joe served as Global Manager for Software Supply Chain Solutions in the Software Integrity Group at Synopsys.  In that role he led efforts to enhance capabilities to mitigate software supply chain risks via testing technologies and services that integrate within acquisition and development processes; enabling detection, reporting, and remediation of defects and security vulnerabilities to gain assurance and visibility within the software supply chain.  Jarzombek has more than 30 years focused on software security, safety and quality in embedded and networked systems.  He has participated in industry consortia such as ITI, SAFECode and CISQ; test and certification organizations such as Underwriters Labs’ Cybersecurity Assurance Program, standards bodies, and government agencies to address software assurance and supply chain challenges.

Prior to joining Synopsys, Jarzombek served in the government public sector; collaborating with industry, federal agencies, and international allies in addressing cybersecurity challenges.  He served in the US Department of Homeland Security Office of Cybersecurity and Communications as the Director for Software & Supply Chain Assurance, and he served in the US Department of Defense as the Deputy Director for Information Assurance (responsible for Software Assurance) in the Office of the CIO and the Director for Software Intensive Systems in the Office of Acquisition, Technology and Logistics.

Joe Jarzombek is a retired Lt Colonel in US Air Force and a Certified Secure Software Lifecycle Professional (CSSLP) a Project Management Professional (PMP) as well as a frequent key presenter at industry conferences. He received an MS in Computer Information Systems from the Air Force Institute of Technology, and a BA in Computer Science and BBA in Data Processing and Analysis from the University of Texas – Austin.


Registration and Networking:    8:00 a.m. to 9:00 a.m.

Opening Remarks:                      9:00 a.m. to 9:05 a.m.

Speaker Presentation:                9:05 a.m. to 12 noon.                   

Lunch (Provided):                       Noon to 1:00 p.m.                                            Q&A:           1:00 p.m. to 2:00 p.m.   

 Meeting Registration: If you would like to attend the May 15th, 2018 Quality Assurance Association of Maryland (QAAM) meeting, please register at

Once on the QAAM website:

  • Click on QAAM meetings
  • Then Click on Meeting Registration drop down next to QAAM Meetings
  • Complete the Meeting Registration form to attend
  • Click <send>.

If you have questions about the QAAM meeting or would like to register after May 11, 2018, please call the QAAM President at 571-232-0683. Fee for the attendance is $35.00 and includes lunch.  Parking is free.  QAAM does not accept credit cards.  There is no fee if your company has a Corporate Membership in QAAM.  If your company would like information about joining, or have any questions, please send us an email at and we will respond promptly.

Directions:  Homewood Suites by Hilton – Note the New Location

8320 Benson Drive
Columbia, MD 21045

To estimate or not to estimate? Not the right question…

Over the past few years I’ve seen an increase in articles and posts about whether or not to do estimation (of cost, schedule and effort) for software development projects. This is especially true when agile/iterative methods are used to develop software for which requirements are not readily known in advance.  There are actual “movements” set up to prove that estimating in and of itself is bad for software development.  At the same time, I’ve worked done more and more work for clients related to software benchmarking (to find best-in-class methods, tools, and combinations to develop software) and estimation (including price-to-win estimating.)  I’m now convinced that “To estimate or not to estimate?” is simply the wrong question – or at least a premature question for many companies.

Estimation is often viewed as fundamental to software development (and any other development projects or programs) as are ingredients to cooking or oxygen to life.  While we might wish to discard or discredit the practice of estimation as an inconvenience and even the reason for software “failures” –(Sidenote:  The Standish group’s annual CHAOS reports cite lack of “on-time” and “on-budget” software delivery as rationale for declaring project failure; both of which would disappear as factors if estimating was eliminated) – the truth is that C-level executives need a level of confidence (based on estimates) to bound their investment in new initiatives, no matter how much faith or confidence the executives have in the development teams’ ability to deliver.  In my humble opinion, project managers MUST  develop skills to do solid, reliable project estimates if they are to survive (and thrive.)  But this is where things often fall apart – estimation is not seen as a discipline based on solid data (in part, because some organizations do estimating haphazardly based on bad data, poor models, flawed assumptions, premature input values taken as fact, among other factors.)

This does not include those organizations where the mere notion of projects (being a temporary endeavor intended to deliver an identified product, outcome, or service such as a piece of software) is like a foreign language.  When I teach courses according to the Project Management Institute’s Project Management Body of Knowledge (PMBOK(R)), it’s not uncommon to find IT pros who profess that project management is not needed because their work is bounded solely by calendar months and the number of full-time-staffers.  The idea that work should be managed towards a specified outcome (with goals, objectives, timelines, milestones, deliverables and a formal end) just doesn’t fit into their paradigm, even for those involved in developing advanced technology solutions.  I’m excluding these companies because projects (and estimating cost and schedule) are actually beyond their comprehension, as is productivity, project comparisons or process improvement.

Given the premise that “to estimate or not to estimate” is the wrong (or at least a premature) question – then what are the right ones?  Here’s a short list:

  • If we do an estimate, do we know what are the correct input variables (and values) we should use?  (i.e., Some idea of scope, non-functional requirements, constraints, goals, project environment, etc.)  Garbage in equals garbage out.
  • When estimating, do we have access to correct and appropriate historical data on which to rely? (i.e., does the historical completed project information accurately depict what actually happened on the project? Often up to 40% of true project work effort is not recorded – or it is recorded inconsistently.)  Incomplete or incorrect historical data make for poor comparisons, and even worse estimates.
  • Are the estimating models we propose, appropriate for the industry and application?  (i.e., in construction, it would be folly to use a home building model for a hospital construction or bridge construction project, so too with software.)  Every model, no matter how advanced, needs to be calibrated for the organization using it.
  • Do we know enough about the object of estimation? (i.e., if it is simply an idea about an outcome without any idea of component programs or projects, a “guess”timate or rough-order-of-magnitude may be the only possibility until more data are known.)
  • Are the estimating exercise/practices paid “lip service” by management? (i.e., does management summarily cut every estimate in half, or dictate due dates that override those of professional estimators?)
  • Does the organization take (software) measurement seriously?  (i.e., how are project measures and metrics collected – if adhoc, inconsistent, without formal processes or procedures to validate the quality of project data, then estimating will likely be equally inconsistent)

These are just a few of the important questions that need to be addressed – before we attempt to estimate and rely on the results of the practice.   When estimating is done without proper planning, discipline and consistency, the results will be unreliable and even worse, downright wrong.

In IT as in life, if you’re going to invest in an endeavor (such as estimating), take the time to do it right the first time, or don’t bother doing it at all.  And that, really answers the question of  “to estimate or not to estimate.”

What other questions are critical to ask?  What do YOU think?