Category Archives: Uncategorized

Walking on Eggshells - a Normal part of Business?

We have all been there – walking on eggshells to avoid outbursts from  a boss, co-worker, or client.  So we skirt the issue, pretend the bad behavior doesn’t exist, ignore the problem, and spend extra time planning how to present an issue so that the person in question doesn’t explode.

While I know that this type of behavior is rampant in business (I’ve experienced it more than once!) – it has serious (and expensive) consequences in the IT industry.  The repercussions stemming from having to “walk on eggshells” to avoid the potential wrath ranges from minor  “oversights” to full scale project failure.

The Challenger disaster is one such failure where group-think and avoidance of conflict ended up costing lives and millions of dollars.  A video chronicling the group think behavior depicts the group-think behavior and steps are taken in companies to address such behaviors. This is all good.

The Walking on Eggshells “syndrome”

Aside from the pressures of group think that encourages teams to conform and cooperate with a single mindset, the “walking on eggshells” syndrome is seldom documented or even discussed.

We all know at least one offender in our workplace!  The offending person may be a narcissist, a control freak, a bully or just plain immature. No matter the clinical diagnosis, our boardrooms and our production labs suffer greatly from their presence.

How much time and money could be saved by confronting these people and addressing the cost of their ‘verbal diarrhea’? Here’s the type of situations I mean:

  • Not raising issues:  “How can we possibly bring up the design flaw for this software now?  The project sponsor will yell and rant if the project is late. Remember how he “freaked out” at the status meeting last month?  Keep going and we’ll address this as an enhancement.”  Cost: could be significant.
  • Cutting corners: “There is no way we can finish the project within the approved budget.  We had no idea that xxx would be so complex, but the steering committee will fire us if we ask for more money. Let’s just cut testing so we can finish the project.”  Cost: could be critical if public safety is at stake.
  • Perpetuating the myth that project plans are right:  “The project plan was based on incomplete data that seemed right six months ago. Now we know more, but with a fixed budget and schedule, we’re stuck. The client will explode if we bring up that the plans were flawed. Let’s just do what we can.” Cost: Corporate learning will never happen (Einstein: insanity is doing the same things over and over and expecting different results.)
  • Skirting accountability: “We messed up on the schedule because we had to program that module 3 times.  I couldn’t understand what they wanted until this time, but we can’t tell Bob because you know how he gets.  I hate it when he yells in a staff meeting.” Cost: could be significant to minor.
  • Wasting time and money: “This project is doomed – the users told us they won’t use the system even if we finish it. The rationale and vision for the project are no longer correct (it’s a dog!) but if we tell the boss about it, you know how she will blame us. I don’t think it is even worth trying to explain it.  Just keep going.”  Cost:  priceless – time and money could be better spent on REAL work!

What a colossal waste of time, money, energy, and morale “walking on eggshells” is to a business!  It is not an easy situation to fix or address – especially when we are talking about people in power who behave badly.

Walking on eggshells should never be part of the way of doing business!  What is the solution?

If YOU were the king of your IT kingdom, what would YOU do?  I’ll publish a summary of responses – add your comments below – or send them privately to me by email to dekkers (at) qualityplustech (dot) com.

Have a productive week!

Carol

Function Points for Mere Mortals... Part 1: NOT Rocket Science

Does this sound familiar?  Your project completed under the “radar” (no major mishaps) and management wants more, more, more!  As part of the quest for faster, better, cheaper, someone in management decides that you ought to be reporting metrics and suggests that everything be built around “Function Points.”  A sponsor (the VP) appoints you the project manager for the Metrics Implementation (aka Function Points) and everything you thought you knew simply vanishes as soon as he walks out the door.

The Internet is Schizophrenic

If you are like most people, your first step is to ask your network (social media, peers, friends, etc.) what these “function points” are all about.  I have written about the simplicity and straight forward nature of Function Points for over 15 years (see downloadable articles below) and yet confusion still abounds in the IT industry!

As you begin to research the topic, thousands of internet links come up offering “Function” or “Points” or variations thereof. Once you find “Function+Points”, the filtered results create confusion as some sources elevate function points to a scientific treatise with the complexity to match.  This is simply not the case – Function Points are a unit of measure used to size the “functionality” of a piece of software that can be used to normalize measurement.  While certain consultants want to elevate Function Points to a mystical religion where only a handful of elders can do a count – this is not the case at all.  (These consultants seek to create an exclusive club where you have to hire them to count – this is utter hogwash!)

This is the point of this post:

Part 1: FUNCTION POINTS ARE not Rocket Science

As I mentioned, I and others publish (and continue to publish) articles and books about function points, yet software metrics is not yet a mainstream practice.  Confusion, disdain, and even downright misinformation abounds about this simple concept – creating a size of software that can be used as a basis (like square feet in a building) for estimating.  This is not Rocket Science!

In Project Management terminology, Function Points are the size of the overall work product for a project whose product is Software.  The WBS (work breakdown structure) for a software project includes all of the software deliverables, and function points is one way of sizing the functionality of the delivered software.  While there are additional things to be considered when doing a project estimate (such as quality, how the software will be built, critical path, resource constraints, risks, etc.) but a fundamental item is the scope.

Function points provides us with a measure of the scope of the software project.  Furthermore, the fundamentals of function points or FP (like the fundamentals of measuring square feet) have not changed in 15 years and counting methods are stable!  Certainly how we implement software has changed, but the functionality and scope have not – so why have FP not become maintream?

Capers Jones published a primer on function points (“Sizing up Software“)  in the December 1998 issue of Scientific American for which the abstract is below:

Modern society has become increasingly reliant on software–and thankfully so. Computer programs routinely execute operations that would be extraordinarily laborious for an unaided person– handling payrolls, recording bank transactions, shuffling airline reservations. They can also complete tasks that are beyond human abilities–for example, searching through massive amounts of information on the Internet.

Yet for all its importance, software is an intangible quantity that has been devilishly tricky to measure. Exactly how should people determine the size of software?

Want more basic information?  Here are four downloadable articles (PDF format) to further introduce you to function points:  (The content is still timely!)

Long and short oN function points? 

They are NOT rocket science and can be fundamental building blocks to a successful software estimating and metrics program.

Was this post useful?  Let me know!

Stay tuned for Part 2:  Getting started with Function Point basics.

Have a productive week!

Carol

Childproof your Metrics Program...

As a new parent years ago, I remember childproofing household dangers like electrical outlets, and raising adult objects above my children’s reach.  Over the years, new hazards appeared and it took planning to stay a step ahead to prevent injury or damage to innocent children.

I remembered this when I thought about what could be done to avoid software metrics failures – perhaps a form of “childproofing” could avoid a few of the dangers involved.

Software measurement is NOT rocket science (despite the claims of a few eager consultants), but neither is it child’s play.  Measurement must be properly planned or it can actually cause more damage than help!

You likely recall Tom DeMarco‘s famous “you can’t manage what you can’t measure” statement, but may not be aware of his later observation that poorly planned metrics can damage an organization.

How to “Childproof” your Metrics Program:

1. Plan a clean metrics program by following the Goal-Question-Metric (GQM) approach. By so doing, metrics are only collected when they serve a specific purpose.

2. Make sure that the measurement team understands the plan.  This will make sure that specific metrics are collected appropriately and that extraneous data are not lying around (or misinterpreted).

3. Pilot the measurement and metrics in a controlled environment before rolling it out. Train the right people to collect and analyze the metrics to make sure the intended results can be achieved.  It is far easier to see dysfunctional behavior (often unintended consequences of measurement) in a controlled environment and minimize potential damage.

4. Communicate, communicate, communicate. Be honest and specific about the project plan: resources, schedule, intended results.  Prepare management not to “shoot the messenger” when early results do not equal their expectations.

5. Limit data access to those who are skilled in data analysis (do not allow management access to raw data).  Proper data analysis and correlation is a critical success factor for any metrics program.

6. Be realistic with management about their expectations.  A program designed to meet champagne tastes (for measurement results) on a beer budget seldom succeeds.  Moreover, sometimes historical data can be collected if available, other times data are impossible to collect after the fact.

7. Recognize that wishful thinking for metrics will not disappear overnight.  Management and staff may not understand that measurement should be implemented as a project:  there will be a need for training (in metrics concepts), planning, design (measurement processes), implementation (initial data collection), training (for the program), communication, etc. As a result, people may give lip-service to the overall initiative without understanding project management is necessary.  Communication and level setting will be an ongoing process.

8. Do not allow data to get into the hands of untrained users.  Often sponsors want to “play with the data” once some measurement data is collected. Avoid the temptation to release the data to anyone who simply asks for access.

9. Do a dry run with any metrics reports before distribution.  After data analysis is done, gather a small focus group together to pilot the results.  It is far easier to address misinterpretations of a data chart with a small group than it is after a large group sees it. For example, if a productivity bar graph of projects leads viewers to the wrong conclusion, it is easy to correct the charts before damage is done.  It only takes one wrong action based on data misinterpretation (i.e., firing a team from an unproductive project when it was actually a problem of tools) to derail a metrics program.

To be effective and successful, software measurement requires planning including a consideration of the consequences (such as dysfunctional behaviors that measurement may cause). Childproofing using the above steps will help to ensure your measurement program achieves success.

Have a great week!

Carol

www.qualityplustech.com

Communicating Quality in a Heavily Wired World - Presentation Slide Share

I’ve been on hiatus (so to speak) since mid-May, but I’m back with miles traveled, countries visited (Canada, France, Ireland), and lots of tech experiences in between – to share with you!

A Gift for you and a Favor…

I spoke as the finale speaker for our Institute for Software Excellence (ISE) conference within a conference (part of the American Society for Quality‘s International Conference on Quality and Innovation in Pittsburgh in mid-May – the topic was the subject line of this post above- which I also affectionately named – No More Death by Powerpoint!

As a presenter, I’m pleased to share with you the link to my slides (yes, with tips for using PowerPoint using PowerPoint slides themselves!) and coordinated audio.  This is my gift to you and I’d be interested in your comments – please let me know what you think!

Here’s the abstract for the presentation:  Quality professionals are passionate about the value and benefits of quality in their work, but when it comes time to present the proof to executives, communicating the value can be a challenge. We are all so busy and overcommitted that we often lose the message in the media. This session takes a look at and offers remedies to common presentation missteps such as “death by PowerPoint,” “tilt- slide overload,” and “duh?”

Now, here’s the link to the full presentation:

Now the favor – can you please fill out the poll below?

I am working with an editor to publish my ebook about Communication for Technical Professionals (Project managers, engineers, scientists, IT) using some of these blog posts –  and I need YOUR help to select a title. Will you help?

[polldaddy poll=5209043]

Thank you!!!

Have a great week,
Carol

Share

Apples and Oranges work in Fruit Salad, not S/W Measurement!

A colleague once observed at a professional conference that “Common sense is not very common” – and when it comes to the typical approach to software measurement, I have to agree.

Case in point – there are proven approaches to software measurement (such as the Goal/Question/Metric by the Software Engineering Institute, and Practical Software & Systems Measurement out of the Department of Defense) – yet corporations often approach metrics haphazardly as if they were making a fruit salad.  While a variety of ingredients works well in the kitchen, data that seem similar (but really are not) can wreak havoc in corporations.  Common sense should tell us that success with software metrics depends on having comparable data.

If only data were like fruit

– it would be easy to pinpoint the mangoes, apples, oranges, and bananas in company databases and save millions of corporate dollars.

Most Metrics Programs don’t Intend to Lie with Statistics, but many do…

I do not believe that executives and PMO’s (project management offices) have malicious intent when they start IT measurement and benchmarking initiatives.  (Sure, there are those who use measurement to advance their own agenda but this is the topic of a future post.)

Instead, I believe that many people trivialize the business of measurement thinking that measurement is easy to do once one directs people to do it.

The truth is that software measurement takes planning and consideration to get it right.  While Tom DeMarco‘s quote

“You can’t control what you cannot measure”

is often used to justify measurement start-ups, his later observations countered it.

In the 1995 essay, Mad about Measurement, DeMarco states:

“Metrics cost a ton of money.  It costs a lot to collect them badly and a lot more to collect them well…Sure, measurement costs money, but it does have the potential to help us work more effectively.  At its best, the use of software metrics can inform and guide developers, and help organizations to improve.  At its worst, it can do actual harm.  And there is an entire range between the two extremes, varying all the way from function to dysfunction.”

It is easy to Get Started in the Wrong Direction with Metrics…

Years ago, I was working with a team to start a function point based measurement program (function points are like “square feet for software”) at a large Canadian utility company, when an executive approached me.  “We don’t need function points in my group” he remarked, “because we have our quality system under control just by tracking defects.” As he described what his team was doing, I realized that he was swimming upstream in the wrong direction, without a clue that he was doing so.

The executive and his group were tracking defects per project (not a bad thing) and then interviewing the top and bottom performing teams about the defect levels.  Once the teams realized that those who reported high defect levels were scrutinized, the team leads discovered two “work arounds” that would keep them out of the spotlight (without having to change anything they did):

1. Team leads discovered that there was no consistency in what constituted a “defect” across teams (an apples to oranges comparison).  Several “redefined” the term defect to match what they thought others were reporting so that their team’s defect numbers would go down. Without a common definition of a defect, every team reported defects differently.

2. Team leads realized that the easiest way to reduce the number of defects was to subdivide the project into mini-releases.  Smaller projects naturally resulted in a lower number of raw defects. With project size being a contributing factor (larger projects = larger number of defects) it was easy to reduce defect numbers by reducing project size.

As the months ensued, the executive observed that the overall number of defects reported per month went down, and he declared the program a grand success.  While measurement did cause behavioral changes – such changes were superficial and simply altered the reported numbers.  If the program had been properly planned with goals, questions, and consistent metrics, it would have had a chance of success using defect density (defects per unit of size such as function points).  Improvements to the processes in place between teams could have made a positive impact on the work!

Given solid comparable metrics information, the executive could have done true root cause analysis and established corrective actions together with his team.

Instead, the program evaporated with the executive declaring success and the workers shaking their heads at the waste of time.

This was a prime case of “metrics” driving (dysfunctional) behavior, and dollars spent poorly.

Keep in mind that Apples and Oranges belong together in Fruit Salad

not software measurement programs.

Call me or comment if you’d like further information about doing metrics RIGHT, or to have me stop by your company to talk to your executives BEFORE you start down the wrong measurement roadway!

Have a (truly) productive week!

Carol

Share
//

Technology at the Speed of Sound... Catch up at Light Speed at LSSC11!

I have to admit that I have not programmed a computer for many years and I have no idea how to write Visual Basic or Java or dot net.  (Yes, I have done raw html and could still manage in SAS if I had to!)

And I can also admit that the proliferation of models and methods from Agile, Scrum, Kanban, Lean, Six Sigma, Xtreme Programming, CMMI(R) (Capability Maturity Model), to manifesto driven systems development,  has me daunted.

Which ones are interchangeable, which are compatible, which are contradictory, and (OMG) where should one start to learn how to avoid the pitfalls?

It’s all a matter of diving in to each and learning the ins-and-outs and best practices — except I know that there are as many opinions about best practices as there are models.

Okay, I can already hear you saying:  “Carol, as a software measurement/Function Point Analysis and PMP (Project Management Professional), you probably don’t need to know much about any of these” — except that I do!

My clients will ask me about these and other emerging topics – and expect that I know the best course of action they should take with Lean/ Kanban/ Agile methods for their company.  And I simply do not have spare time to read all the books, experiment, fail, try again, and then decipher what is hype and what is real in this space!

So what is a sane, intelligent, forward thinking IT professional like me to do when faced with an overwhelming mountain of information like this so I can properly advise my clients?

The answer is: ATTEND the Lean Software & Systems Conference 2011 (#LSSC11)!

There is no other conference in the same timeframe that offers more than this growing conference!

Being held 3-6 May, 2011 at the Hyatt Long Beach in Southern California, this annual conference boasts over 90 speakers over a 3 day period on topics ranging from:

See the full program at http://lssc11.leanssc.org

All given by practitioners and experts for practitioners!  And the majority of presenters have real world, hands-on experience in the trenches with Kanban, Lean, Agile and Scrum and lived to tell about it!

Why not catch up to technology racing at the speed of sound by accelerating your learning Light Speed with LSSC?

There is no similar conference offering the breadth or depth of topics, experience sharing, or real case study results in the Kanban and Lean software development space.

And the May 5, 2011 Brickell Key awards for excellence in the advancement of Lean in software development will recognize some outstanding nominees working in the area – some of which are professionals just like you!

I know that I will catch up on these major topics and more – in record time – by attending LSSC11.  If you are an IT professional, don’t you owe it to yourself to check it out?

Read about the Program and the Speakers at LSSC11 and register today!

Wishing you an eventful and productive week and I hope to see you in Long Beach on May 3, 2011!

Regards,
Carol

Share

Whose job is IT anyways?

The title was a purposeful play on the acronym “IT” (information technology) because there is often no one person who takes responsibility for failed IT projects. In addition, it is not as if there are not project failures everywhere.

Notwithstanding one of my least favorite (but often quoted) research studies, the Chaos Report cites that about one-third of projects are successful when it comes to IT.  What gets in the way of project success?  Lots of circumstances and lots of people!

When a software intensive project fails, there is no lack of finger-pointing and blame sharing – yet seldom do teams stand up and confess that the failure (over budget and behind schedule and failing to meet user needs) was due to a combination of over and under factors, along with fears:

  • overzealous and premature announcements (giving a date and budget before the project is defined);
  • over optimistic estimates of how quickly the software could be built;
  • under estimation of the subject complexity;
  • assumptions that the requirements were as solid as the customer professed;
  • under estimation of the overall scope;
  • under estimation of how much testing will be needed;
  • under estimation of how much time it takes to do a good job;
  • under estimation of the learning curve;
  • under estimation of the complexity of the solution;
  • under estimation of the impact of interruptions and delays;
  • over anticipation of user participation;
  • over optimism about the availability of needed resources;
  • over optimism about hardware and software working together;
  • over optimism about how many things one can do at once;
  • risk ignorance (“let’s not talk about risk on this project, it could kill it”);
  • over optimism of teamwork (double the team size doesn’t half the duration);
  • fear of speaking up;
  • fear of canceling a project (even if it is the right thing to do);
  • fear of pointing out errors;
  • fear of being seen as making mistakes;
  • fear of not being a “team player”;
  • fear of not knowing (what you think you should);
  • fear of not delivering fast enough;
  • fear of being labeled unproductive;
  • fear of being caught for being over or under optimistic.

Therefore, I ask you, on a software intensive IT project, whose job is it to point out when there are requirements errors, or something is taking longer than it should, or it is costing more than anticipated. In traditional waterfall development because there’s so much work put into the planning and documenting of requirements, pointing out errors are  either no one’s job or the team’s (collective) job which really relates to no one’s job.

Often it is easier (and results in less conflict) to not say anything when the scope or schedule or budge go awry on a software project. Yet it is this very behavior that results in so much rework and so many failed projects.

Agile and Kanban projects are different

Several of the advantages to using Kanban and Lean and Agile approaches to software and systems development is that the methods address the very items outlined above.  Building better software iteratively becomes every developer’s job rather than no one’s:

  • Fear of pointing out errors is removed because the time that goes into a scrum is days and weeks not months (so participants don’t get defensive about change);
  • Over and under optimism remains but is concentrated on smaller and less costly components of work (i.e. days instead of months or years);
  • Risk is not avoided or ignored because we are no longer dealing with elongated and protracted development cycles (spanning seasons);
  • Assumptions come out with better and more frequent discussions;
  • Over optimism about how many things one can do at once is removed because Kanban limits the amount of work-in-progress;
  • Under estimation of the impact of interruptions and delays is minimized because such factors are addressed in Kanban;
  • Over anticipation of user participation is managed through direct user involvement.

What do you think?  Join us at the Lean Software and Systems Consortium conference LSSC11 from May 3-6, 2011 as participants and speakers address the best ways of advancing software and systems methods including Lean, Kanban, Agile and other exciting new ways to deliver high quality software more efficiently and effectively.

These newer approaches make it easier for everyone in IT to make it their job to build better software.

Wishing you a productive week!

Carol
@caroldekkers (twitter)

Share

The importance of Being There (at work)!

Did you know?

Only 26 percent of IT employees in North America are fully engaged at work, while 22 percent are actually disengaged, according to a global study by consulting firm BlessingWhite.

Being there…

At a time when unemployment is at an all-time high, only one-quarter of IT workers are fully engaged or Wowed by their work, while the remaining 75% just go through the paces or don’t care at all.  When you consider specific industries fraught with frustrations of rework (exceeding 40% in some areas) and impossible deadlines such as in waterfall development, I would bet the excitement factor of going to work is even less.

#Kanban, #Lean, and #Agile communities are exceptions

The Agile Manifesto recently celebrated its 10th anniversary last month, and Kanban, Six Sigma, Lean, and Agile methods now share space with waterfall as leading methods in the software and systems development space.  Agile (in my humble opinion) was one of the first to restore a sense of sanity in software development.  In earlier times, a group of  business customers with rapid fire changing requirements would challenge software developers (tired of the constant change and “jello” like demands) for amorphous software products.  The result too often – failure.

It makes sense, in this type of environment, to do iterative development.  It was illogical to do the opposite: long development cycles to produce products already obsolete before they hit desktop computers.

Approaches like Kanban, Lean, Agile, Personal Kanban and others continue to transform our industry and inspire software developers to become “fully engaged” in the work.

Less head banging… but you have to engage

Certainly there is head banging and more job satisfaction in this new world (if “tweet volume” is any indication, the Kanban/ Lean/ Agile communities are a happier lot!) but it takes commitment to show up and be part of the action.

I believe that the Kanban and Lean and Agile communities know the importance of really being present and engaging at work.  We also know it is critical to create a community of like-minded people who meet in-person – at conferences, local meetings, at social events.

LSSC11 is coming soon!

The landmark Lean Software and Systems conference is only 10 weeks away in Long Beach, CA on May 3-6, 2011.  Make your choice of conference to attend in 2011 the LSSC11 (especially if you can only attend one!)  See my related post Top 10 Reasons to attend LSSC11.

Join the movement of people who know the Importance of Being There in software and systems development: The Lean and Kanban and Agile communities.  I hope I will meet you at LSSC11!

Have a Wow! and engaging week at work,

Carol

Share

Pre-flight email checklist: THINK before you click...

I AM OVERWHELMED BY EMAIL!

There I said it, I am overwhelmed with email and I can’t stand it!

I thought I was the only one until I read Tim Tyrell-Smith’s post today: How to reduce the Quantity of Incoming Email and realized that there should be a pre-flight email checklist to save our sanity… and to encourage Thinking before Clicking!

Since joining the world of social media I realize my “connectivity” has grown exponentially, but not all in a good way. Even with my SPAM filters set to high, I get so much email that it is overwhelming!

I feel like I must have ADD (attention deficit disorder) because my day is interruption after interruption (sorry TweetDeck!) and I need help (and I know I am not the only one!)

Pre-flight email checklist (THINK before you click):

  1. If it takes longer to write an email (to one person) than it does to walk across the hall / call the person, don’t write an email. Pick up the phone or get up from your desk.
  2. If multiple people are involved and you need responses, consider whether a one hour meeting would work better than filling up in baskets with back and forth threads for the next 2 weeks.  If so, schedule a tight meeting and solve the issue in one fell swoop.  (Just because it doesn’t take paper doesn’t mean email is green — it can litter cyberspace!)
  3. If 1 and 2 are not possible, consider other options: Twitter or a blog post or an update at a staff meeting might be better than email.
  4. You’ve thought through 1,2 and 3 and decide your message needs an email.  Never negligently click “Reply all!”  unless you’ve gone through these same steps:Make sure you set aside a dedicated time (10 minutes minimum) to THINK before you click:
  • Consider your recipient: Walk for a moment in their shoes and think: what would be your response to this email? Make sure to emphasize the key points (i.e., make the reason for the email crystal clear). Do not “assume” that everyone shares your knowledge so give necessary background.  In the words of Peter Drucker:  It is important to state the obvious otherwise it may be overlooked.
  • If you expect/need a response, be clear about it. Tell recipients what you need from them (each), by when, and how (call, email, comment, decide…).
  • If it is an information only email, say so. No one has time to read your mind.
  • Consider using the subject line as a filing cabinet: Use tags to identify topics and intent. E.g., ABC Department meeting notice, Feb 17, prep material attached; or Dekkers: Blog Marketing draft – comments needed by Feb 20, 2011.  In this way, recipients can quickly find YOUR email from a pile in their in basket.
  • Consolidate information! If the email is about a meeting: include dial-in information (top and center for easy access!), meeting date and time, and  attach all preparatory material all together in a single email. There is nothing worse than having to pull up 3 emails to get ready for a single meeting!
  • Preview before sending: Spellcheck, attach files, check all recipients are included.
  • If there is emotion involved save the draft email and wait a full day (or at least an hour) before doing the doublecheck and send step below.
  • If it’s a regular email (non-emotional), take a one minute break – stand up, look out the window, anything to clear your head. Then go back and re-read your email, double-check attachments, recipients, bcc’s etc.
  • When you are sure it looks right consciously hit “send”. NEVER hit send when you are multi-tasking (i.e., on the phone). Once an email has been sent it is in cyberspace FOREVER (regardless of rescinds!)

I plan to follow this checklist starting today! What do YOU think? Do you have any additions?

p.s., DON’T forget to sign up for my Feb 17, 2011 (11am – 12:30 pm EST)  FREE Webinar:  Navigating the Minefield – Estimating before Requirements.

Register here: http://tinyurl.com/6flgjwr

To your increased productivity!
Carol

Share

Superheroes in IT, come down to earth…

Are you a technology superhero?  Then you might want to read this (and even comment!)

Information technology is a widely misunderstood part of business:  executives view us as a necessary evil, yet do not understand  IT is an investment.  As technology professionals, we lament our treatment as suppliers (or even servants) instead of business partners, and spin our wheels trying to prove that we add value to the business. What we fail to see is that we unwittingly contribute to the dysfunction with a superiority complex that we project on the business.

We view ourselves as technology superheroes, while the rest of the world sees us as overpaid intellectuals lacking in social skills.  There is no right or wrong here, just misunderstanding on both sides of the relationship.

The Superhero World

As software engineers, it is hard to imagine that the world thinks any differently than we do.  We take for granted how we learn, digest and embrace new concepts, so much so that we assume it is universal.  Certainly, we recognize genetic individuality, but we assume thought patterns are common. When we assimilate new ideas easily, we assume that others can too. We reinforce our beliefs by seeing co-workers behaving the same as we do.

This is a major issue in IT and engineering (and other professions as well) where success hinges on clear communication and a shared understanding of business needs. As software engineers and product developers, we live in an insulated world – one laden with technical terms and concepts, and life as we know it can be exciting!  We are the superheroes in IT – we use Kanban, Lean, and Agile to get close to our customers and we develop advanced software solutions that make the world better in a single bound.  Or so we think…

The world would be perfect if we could concentrate on doing what we do best – building great software solutions – without interference from the outside world. The problem is that we have to deal with “mere mortals” in business, and for some reason we are simply not on the same page. Herein lies the problem:  our assumption that the world thinks the same way that we do.

As superheroes in the IT world, we ARE different, but we need to function in the real world.  We are addicted to technology but others are not… so who has the problem and what can we do about it?

First steps…

The first step in solving any problem is to admit that it exists and take responsibility for our part.  This means taking a hard look at our role and what we can do to change the dynamics of the business / IT relationship.

Here are a few ways that we can take responsibility for improving the relationship:

  • Realize that the way we look at the world is not universal. As software engineers our passion for technology is hardwired, just as others are hardwired with passion about banking or marketing. My professors (and maybe yours) taught that everyone aspires to engineering and computer science, but few can make it, and this created an elitist view of the world.  I now know how this attitude projected a sense of superiority and entitlement to special respect that is simply, undeserved. Recognizing these differences is the first step to humility and true communication.
  • It might sound impossible but… technology IS intimidating.  Moreover, the subject can be boring to others. The world does not share our zest for IT English – we may be superheroes when it comes to creating technology solutions, but that does not make it interesting to others. While it might seem like “dumbing down” when we translate IT English into business English, there is no other way.  If we continue to talk our talk without consideration of others – well, we sound unintelligible.  (Just watch an episode of the TV show “Big Bang Theory” for a glimpse of how techies seem to the world).
  • There is no base level of idiocy. Many technical professionals believe that there is a base level of knowledge idiocy.  In IT, we dismiss anyone as an idiot whose technical knowledge is below this “line” and then treat him/her as a lesser being. While we do not necessarily do this consciously, it comes across in the way we talk down to non-technical people.  Sure, doctors do this, lawyers do this, and software engineers do this, but it does not promote good relationships on projects. The sooner you realize that your basic level of knowledge (such as knowing about the software development life cycle or communication protocols) is above the general population, the better off you will be.  While you and I might be aghast to realize how little most people know about software concepts, they do lead successful and productive lives without this knowledge.  We are the idiots if we cannot translate IT English so our customers can understand, not the other way around.
  • Read outside your world. If we want to understand how our customers think, we need to explore outside the world of technology. Find out what journals your customers read, and pick up a copy. When you start to understand what your customer’s world is all about, you can start to solve their problems.
  • Accept the world that is. Engineers are known the world over as being great at technology and poor at communication.  Instead of denying this fact and defending ourselves, we ought to accept it, improve it, and move forward.  Communication and soft skills can be learned, but we first have to admit that we need help.  I know many software engineers who behave as ostriches by burying their heads in their work and avoiding customer contact.  Why not accept the world as it is and improve on it through education?  Ignorance is bliss except when it comes to communication – and the good news is that communication can be learned.

If we want to garner respect for the IT superheroes among us, we need to come down to earth and live among the “mere mortals” (non-IT).  Only then can IT save the world.

What do you think?  Agree or disagree? Comments?

Carol

Share
//