Maximize project success-- get a communication skills "tune-up"

Abstract

Can you imagine contracting with a builder by telling him that you want a house built within a preset budget amount, and then leaving him alone to rely on his telepathic powers to get your requirements and design done right? That would be absurd as we know that construction and other design intensive industries rely on good requirements and effective project communication to deliver a high quality product. With project requirements go, two aspects are critical:

  • gathering the right user/owner requirements, and
  • getting the requirements right (ie. using the right set of processes to deliver those requirements).

The former concentrates on the project management front end processes (effectively gathering and eliciting project requirements), while the latter focuses on effective performance of project management processes (scope containment, change management, earned value management) to develop the product. Throughout all stages of the project, whether a software or construction project, there is a pervasive and consistent reliance on effective communication. Effective communication (and understanding!) is critical during all project management phases from gathering requirements to dealing with people to managing tasks to scheduling milestones. (Dekkers, 2003)

Communication in cost and resource intensive projects such as software development and building construction is particularly critical to project success. Because quality is in the eye of the beholder (user), there are three components that must be properly managed: a) Getting the “right” requirements, b) performing the “right” development processes, and c) effective communication. An informal internet survey of websites offering project management education shows a predominant focus on technical processes and procedures (CMM®/CMMI(sm), SPICE, ISO standards, Baldrige, etc.) i.e., doing the right things, with a lesser concentration on getting the requirements right. Where there appears to be a gap is in the communication area – perhaps it is because project “soft skills” are seen as “soft” – i.e., less important than the technical expertise already possessed by project managers. For computer scientists, engineers and other technically proficient project managers, this will come as no surprise as it reinforces the approach in technical college classes that communication courses are of little importance. Given this dearth of communications training (who ever heard of a computer scientist going into the field to gain “people skills”) coupled with new statistics illustrating the urgent need to improve software requirements, this paper presents a quick and easy communications tune-up to equip project managers with the knowledge about how to improve project success through effective communication.

Introduction

The key to product quality lies in getting the right requirements, and getting the requirements right. Statistics for the software development industry projects are collected annually. Recent statistics illustrate the urgency of needed improvements:

  • Rework = 40% of software development effort (Nelson, 1998)
  • Requirements errors contribution to delivered product defects = 60-99% (Insight, 2002)
  • Project success rate = 34% of all projects (Standish, 2003)

The software industry is addressing these issues as well as customer demands for better products, delivered faster and cheaper. The solutions are varied and embrace principles and processes for higher quality including the Capability Maturity Model (CMM®) for software and the Capability Maturity Model Integration (CMMIsm), faster delivery methods such as agile development and extreme programming, and cheaper product development using commercial off the shelf (COTS) packages or reusable code. What is seldom mentioned, however, is that the underpinning of all of these improvements is clear and effective communication with customers, stakeholders, management – in other words, the entire project team. For the remainder of this paper we'll focus on how to improve communication particularly on software development projects because:

a)  Software projects are some of the most communication challenged projects that a project manager can undertake;

b)  The author is intimately familiar with the software development team issues – particularly the challenges of working with language and terminology issues across multi-disciplinary teams with technical and nontechnical professionals;

c)  Software is pervasive in our society and software project failures are widely studied and reported on in mainstream publications; and

d)  The principles and strategies outlined here can be easily transferred and applied to other industries.

The Importance of Communication

Communication skills are often mistakenly taken for granted, especially when it comes to software projects when everyone on the project team speaks English. As such, it is naturally assumed that “basic” principles known to IT professionals are common vernacular to everyone on the project team. According to the fact that 60-99% of defects in delivered software can be traced directly back to requirements errors, a communication tune-up could provide increase project success simply by having team members talk the same language. Imagine the gains if effective communication then went beyond the requirements and facilitated a fully functional, well tuned, highly productive project team that was like a well oiled engine? Using an automotive tune-up as a metaphor for our communication tune-up may illustrate some of these potential gains.

Communication Tune-Up

A traditional automotive tune-up ensures that a vehicle is fit for optimum performance through a few inexpensive replacement parts such as filters and oil, and that all belts and timing are aligned. According to DocsMotorworks (Docs, undated):

“Electronic ignition, computerized engine controls, and electronic fuel injection have eliminated many adjustments that were once part of a “traditional” tune up. Most would agree that a tune-up today is a preventive maintenance service and engine performance check. A complete tune-up should combine elements of preventive maintenance, adjustment and performance analysis.

Things like hard starting, stalling, hesitation, misfiring, poor fuel economy, or lack of power are seldom cured by a new set of spark plugs and a few turns of a screwdriver. Every tune-up should include a comprehensive performance check to verify that no derivability problems or trouble codes exist. Taking into account longer service intervals and reduced maintenance requirements of today's vehicles, a tune-up is probably only necessary every 30,000 miles, or once every two years.”

With today's project management training and computer science cirriculums starting to include communication as optional coursework, we are becoming more like today's vehicles in need of less frequent tune-ups. But, no matter how long we've been in the industry or how recent was our college attendance, a communication tune-up will realign our thinking so that we can optimally interact with our project teams. We have modelled our communications tune-up on the basic automotive model:

“Put in new spark plugs, replace the distributor cap, air filter, fuel filter, and check your timing,” said Jim Alson, an engineer with the U.S. Environmental Protection Agency (Edgar, 2002).

If you haven't looked at your communication skills seriously since high school or college, our tune-up is an easy way to refresh and realign. Ultimately, if we can increase the requirements process by even a percentage point through better communication, we're on the road to improved software quality. The checkpoints in the communication tune-up include:

  • Project Starters (Spark Plugs)
  • “User” Requirements (Filters)
  • Networking is Critical (Oil Change)
  • Project Management (Distributor Cap)
  • Learning to Learn (Check Timing)
  • Watch for Good Wear and Potential Burnout (Checklist of parts and wear)

Each tune-up step is presented in its own section in the following format: (a) why is the item important?, (b) supporting evidence, and (c) tuning your skills.

Project Starters (analogous to changing spark plugs)

Why is the start of a project important for effective communication? Project initiation sets the mood for the project, and first impressions set at this time establish positive or negative reactions that last. Attention to detail during project initiation is similar to replacing the spark plugs on a car – it ensures ignition for a smooth operating session (the project). To illustrate how important first impressions are, imagine yourself in a foreign country that does not speak English. If your first encounter with a countryman is friendly and patient, it is likely that your overall impression of the society will be positive. Equally, if the encounter is negative and makes you feel inferior for not knowing the language, it is likely that you will establish a negative stereotype of the culture. (This situation is played out daily when employees of a well known electronics company expect you to know technical details of products to shop there, while a home improvement company that sells many of the same consumer products will treat you as a consumer rather than a technocrat. The result is that you will be more likely to shop at Home Depot when you don't completely know which product to purchase, while Radio Shack might be more attractive when you know the exact technical specifications for the product you want to purchase.)

Paying attention at the beginning of the project is even more important when there is not a face-to-face meeting because communication normally conveyed through an in-person meeting can be misinterpreted when the visual connection is not made. Communication is 7% verbal and 93% visual, and we become entirely dependent on the verbal words and tone when we are not at an inperson meeting.

Supporting evidence:
  • Shyness: Networking maven and author Susan RoAne (RoAne, 2000) cited a Stanford University study: in 1995, 88% of adults identify self as shy (up from 80% in 1980s). Why has the shyness percentage gone up? Advancements in technology were cited as a factor – with email and voicemail it is easier for people to convey their messages without having to actually directly interact with another person.
  • Misfires: RoAne also cites that the number 1 social fear today (as reported in the NY Times) is “A party with strangers” – for example walking into a roomful of people you don't know. The number 2 social fear is speaking in public. As such, people are afraid to express their opinions in front of people they do not know for fear of rejection. Project teams where the participants are strangers to each other formulate a risk filled situation – this can lead to poor requirements articulation.
  • New terrain: “Face-to-face contact with bosses, employees, customers will become newly important.” (Strauss, 1999)
Tuning your skills:

Pay attention to the use of acronyms, technospeak and other IT colloquial conventions when communicating with non-technical project team members. This will increase the comfort level of all team members and facilitate clear communication. Once project team members understand the importance and lasting effect that first impressions can, they can instill in a project the attitude of caring and sincerity by paying attention to the words, stances and visual cues they project.

“User” Requirements (analogous to changing oil, fuel and air filters)

Why are filters on requirements important? Software developers are similar to master craftsmen on a construction project in that often the project requirements are presented as one consolidated set of requirements – totally “unfiltered”. In fact, these project requirements can actually be broken down and categorized as three distinct types of requirements:

  • Functional user requirements (What the software must do);
  • Non-functional user requirements: (How the software must perform); and
  • Technical requirements (How the software will be built).

The users / specifiers of the software are ultimately responsible for the first two requirements types, and developers are responsible for the technical requirements. However, when we “ball” up all of the requirements together because that is the way that that we “technical” specialists need to work with them to build the software, we obscure the purity of what the user/business communities require from the software in terms of “what it must do” (the functional requirements) and “how the software must perform” (the non-functional or quality requirements). This is similar to what would happen if you asked a mechanic to change your oil filter (a functional requirement) and they responded by telling you the various makes and models of filters and their physical attributes, then asked you which filter you wanted him to install. Your response would typically be: whichever one will work the best for the money – and the decision of the delivery type would ultimately be left up to him.

Today's software project teams feature a mix of technical developers and non-technical users with a myriad of skills, expertise and technical knowledge. Even seasoned users with years of project experience will admit to frustration with technical jargon on software projects. While many understand the risks associated with poor requirements articulation, it is often a matter of personal face saving that leads to silence. Psychologists have noted that people in Western cultures “underestimate the degree to which their behavior is affected by their concerns with preserving face and avoiding embarrassment,” (Lerche Davis, 2003). Does this affect project team performance? A proper filter in an engine keeps the motor running smoothly, just as creating a safe and effective communicative project team is critical to the smooth software project. Further, people underestimate the degree to which they are influenced by others. “It's hard to know why, but part of it may be the American ideal of marching to your own drummer. We grow up thinking we shouldn't be affected by what others think.” (Lerche Davis, 2003)

Zig Ziglar also stresses the need for mutual understanding in business: “you need to understand the other person's perspective. Not only does a good quarterback study how to run an offense, but he also studies to learn the defensive psychology and strategy as well. That way, he has a better feel for how to accomplish his objectives. You also need to think like the other person thinks so that you can speak in understandable terms. I love the story of the doctor's wife who called a plumber because she was having trouble with a toilet. The plumber asked her, “What's the problem?” She said, “The toilet can't swallow.” That was a language she knew that they both understood.” (Ziglar, 1998)

Supporting evidence:

In the book, Waltzing With Bears: Managing Risk on Software Projects (DeMarco, 2003), Tom DeMarco and Tim Lister propose a new Win-Win Alternative for software projects It specifies the following critical components: Up-front commitment to seek out all stakeholders

Solicit from each one the so-called win conditions that will lead to project success from his/her point of view. Remember that conflicts (communication barriers) become risks.

By keeping in mind that project stakeholders can digest requirements within their area of expertise and assembling project documentation for user review strictly on the functional and non-functional requirements, up front commitment is within easier reach. Conflicts occur when people do not understand enough to even formulate intelligent questions, and technical (how to build software) requirements create ample opportunities for misunderstanding.

Tuning your skills:

Create requirements “filters” to keep requirements types (functional, non-functional and technical) pure and discrete. This allows for clarity of communication with stakeholders. When project participants understand what is expected of them (review tasks) and understand the materials they are asked to review (functional and non-functional requirements), everyone feels better about their participation. A recent study out of Wake Forest University gauged the importance of “social” approval and disapproval on people in general:

“The results of this study show that social approval and disapproval affect virtually everyone's feelings about themselves, even those individuals who steadfastly and adamantly claim that their feelings about themselves are not affected by other people's evaluations.” (Wake Forest, 2003).

What this means to our projects is that we have the opportunity to increase team productivity through clear communication. Ensure that project participants are capable of doing the tasks set out for them by assembling clearly written documents with appropriate content. Once a review is completed and turned back in to the project team, it is also important for technical team members (especially the project manager) to positively acknowledge the contribution.

Networking is Critical (analogous to an oil change)

Why is networking an important part of effective communication? In today's over-stressed project environment where no one has extra time, networking becomes an essential tool to leverage needed expertise beyond the reaches of your project team. Consider it in this way: if you have X amount of knowledge, then it follows that three persons at your level will collectively have at least 3X knowledge (ignoring the common IT knowledge). Networking is the “oil” that allows you access to those people and their expertise. Imagine being able to tap into expertise quickly while avoiding the pitfalls of gathering the information first hand? This is essentially what a well oiled network can provide to you and your project. While you may not think you have the makings of a networking professional, it is likely you've already got the core ingredients (people you've met) and simply need to restore the connections (make contact) and add high quality oil (effective communication). A network provides for easy access to specialized of expertise at a cost far less than the cost of acquiring it first hand. Networks are a key factor to building better software faster and more effectively.

Supporting evidence:

Much has been written about the importance of networking in our everyday life, and even a few noted authors have asserted the importance of networking on business interactions. A few definitions of the word “network” include:

  • “Relationships {that} determine success.” (Crosby, 1988)
  • “A spider-web type matrix of people and contacts that coordinates connections and cements relationships” –Carol Dekkers
  • “The world is a Network of Relationships” (Baker, 1994)

Wayne Baker expounds on the Five Networking Principles in Networking Smart (Baker, 1994):

  1. Relationships are a fundamental human need
  2. People tend to do what is expected of them
  3. People associate with others like themselves
  4. Repeated interaction encourages cooperation
  5. It's a Small World

Without going into detail on these points, it is sufficient to say that networking can be a powerful way to leverage the expertise of others when and how you need it on your project.

Tuning your skills:

Conscientiously decide to make a note of everyone you meet (the back of a business card is a great place to make notes!), including where you met them, what they do, and any specific expertise they shared with you. Follow-up with a short email or note to remind them that you met and then store their contact information for potential later retrieval. Ensure that you make frequent contact to exchange information of mutual interest (might be to send a link to an interesting article or website), so that you establish a working relationship prior to asking them for information if and when you need it on your project. People like people like themselves, and are genuinely interested in exchanging information if it is not construed to be a “user” situation (i.e., they are being used). Simply making and keeping connections with the people you meet and showing continued interest in their work and their lives will create a lasting network you can leverage for success.

Project Management (analogous to replacing the distributor cap)

Why project management is important to effective communication: Core project management principles (planning, reviewing, tracking and controlling) are critical to ensuring a well run project. If there are “cracks” in the project in terms of unplanned tasks, lack of schedule dates and milestones, and little minimal project tracking and control it is likely that the project will fail. Simply having project management, however, without communicating the plans and schedules to team members, will not guarantee success either – it is the combination of good project management and good communication that provides opportunities for success. Good project management starts at requirements and ensures that not only are the “development processes” on the project aimed at delivering the requirements right, the right requirements will be developed.

What does it mean to develop the right requirements? According to the Institute of Electrical and Electronic Engineers (IEEE) standard 830 (IEEE, 1998), a comprehensive checklist of requirements attributes is important for quality:

IEEE Criteria
Complete
Consistent
Correct
Feasible
Modifiable
Necessary
Prioritized
Testable
Traceable
Unambiguous

Requirements that pass all of these criteria are considered to have what it takes to become high quality software. As you scan the list, you may note that the majority of these checks require solid communication among project team members. Simply the act of being able to check off the attributes requires discussion and agreement, which is an essential part of effective communication.

Supporting evidence:

Peter Morris in his study on Project Management results claims that Requirements are the # 1 reason for lack of project control (Morris, 1994). By starting project management early in the development life cycle, communication mechanisms are built in. Using the IEEE standard 830 facilitates the discussions about requirements and whether they are ready for progression into the next phase of the software development life cycle.

Tuning your skills: Access and learn the essentials of project management and how to plan, schedule, track and control each phase of software development. Along with the recommendations presented in #2. User requirements (separate out the three types of requirements), also use the quality checklist on each type of requirement to ensure that they are robust and complete enough to progress through to the next phase. The act of creating plans, agreeing on dates, setting goals and milestones and tracking progress are communication heavy – and agreements achieved among all project team members will be critical to ongoing project success.

Learning to Learn (Check Timing)

The second to last step in this communication tune-up is to understand how people learn and gauge their reactions to ensure that learning and knowledge transfer are actually taking place.

Why is learning how people learn important to effective communication? When we are working with individuals, we need to be cognisant of the fact that there are various learning styles, the preference for which depends on the person involved. As such, technical and non-technical project team members alike will each have their best method of learning, and training, presentations, reports and other project communication vehicles must appeal to all types of learners to be effective. Training that is targetted for only one type of learner will naturally fail to be all things to all learners, and will run the risk of being a time waster for the majority of participants.

What are the types of learners? Visual, audial, and kinesthetic, with a fairly even split between each type in a general population. Visual learners need icons, clipart, visually attractive surroundings and recall details based on colors, pictures and positioning. Audial learners rely on the written or spoken words, how they sound and who is speaking. Often audial learners find themselves impatient with monotone speakers who do not moderate their voice pitch. Kinesthetic learners rely on touch and tactile experiences to fully grasp and recall new concepts. This type of learner likes hands-on activities (such as story boards, post it note wall exercises, and experiential activities) over visual or audial appealing presentations.

Supporting evidence:

The benefits for expressing requirements through more than one presentation method were touched on in a 1997 issue of CrossTalk:

“If all system requirements are mapped to test cases, and all test cases are passed, it is reasonable to assume that the system will meet the intended purpose. Although this goal can be achieved through the use of OO models, conversion of models into plain language can reduce ambiguity and help clearly define the system requirements.” (Doernhoefer, 1997)

Tuning your skills:

Begin to use a variety of presentation methods that will appeal to all types of learners on your project team. Some suggestions to meet the needs of these groups include:

  • Visual: Context diagrams, flowcharts, storyboards, stickman (usecase) models, graphs, screen and report mockups
  • Audio: presentations, spreadsheets, conversation, staff meeting discussions, conference calls, tables
  • Kinesthetic: story boards, prototypes, screen mockups,

In addition, the effectiveness of all training programs should be assessed to ensure learners have properly grasped the training materials to the extent you anticipated. Training workshops where learners recall only the first and last 15 minute segments, where the timing was too early or late before the concepts are needed, or where the concepts were either too advanced or too basic, lead to ineffective results. To find out how good or bad training experiences are for project participants, simply ask, and make the situation safe (refer to Project Starters again) for respondents to tell you the truth. Ineffective training the first go-around can be corrected for the next session, but ineffective training that continues uncorrected quickly drains a project of valuable time and money that could be better spent elsewhere. Since we barely have enough time or money to do things right, we need to stop ineffective communication as soon as it Is detected.

Watch for Good Wear and Potential Burnout (Checklist of parts and wear)

The last step in our tune-up process is to take note of the things that are working well in our project “vehicle” and observe the things that are operating efficiently and be on the lookout for potential soon to expire (burnout) parts.

Why is Watching for Good Wear and Potential Burnout important to effective communication? Project managers aim for results and know that there is nothing quite as gratifying as a solid project completion and a high quality product delivery. Just as a tune-up focuses attention on making sure the car is in top operating condition through preventative maintenance – most project communication (and our tune-up thus far) focusses on effective and efficient processes and parts. With such a concentration on final delivery and making the team deliver, it is easy to overlook the little things that lead to successful conclusions. Steven Gaffney states “One of employees biggest complaints is a lack of appreciation. It is astonishing if you think about it because appreciation is often free. I have yet to hear of someone who left an organization (or a marriage for that matter) because they were appreciated too much. It's usually quite the opposite. We all want to know that our hard work is making a difference. (Gaffney, 2004)

Supporting evidence:

Relationship guru Zig Ziglar sums up the importance of noticing the little things and appreciating people in his Ten Commandments of Human Relations: (note point 7 in particular) (Ziglar,1998):

  • Have unshakable integrity, a good attitude, and thorough knowledge of the skill necessary to do the job well.
  • Smile and speak to people. That's elementary, isn't it? It takes 72 muscles to frown and only 14 to smile. And a smile is the first thing that you notice about others.
  • You've heard it a thousand times: Call people by name.
  • Be friendly and helpful. If you meet somebody with a chip on his or her shoulder, the best way to get it off is to let him or her take a bow.
  • Speak and act as if everything you do is a genuine pleasure.
  • Be genuinely interested in other people. You can like almost anybody if you really try.
  • Be generous with your praise and careful about any criticism you have. Remember, the best thing to do behind a person's back is to pat it.
  • Be considerate of the feelings of others.
  • Be alert to give service. What counts most in life is what you do for others.
  • Develop a good sense of humor.

It is easy to overlook these “little” things until their neglect turns them into major obstacles. While automobiles don't have feelings, people do. When things are going well on a project, it is easy to overlook the fact that it still takes effort and concentration to make things appear to run smoothly. Often when things are going well on a project, there have been silent concessions and compromises made that often go unrecognized.

When a car's braking system is working well, one might argue that the pads are not worth checking for wear. However, once the brake pads get too worn down, they will overheat, start whining, and if ignored will eventually lead to brake failure (and a potential accident). The same is true for communication – a smile and a thank you go far further than an unacknowledged frown and a huff that “it's part of their job”. At a major conference keynote presentation a few years back, the speaker noted that they had saved a handwritten note from a boss from years before and still recovered the worn edge envelope when they needed a lift in his new life as the CEO of a major corporation. Acknowledging the little things frequently and sincerely will create a foundation for loyalty when the project falters in the future. A bit of verbal “honey” works better than financial rewards in today's marketplace. It is also important to watch for human resource burnout before it happens on your project. Just like air conditioning cannot function on the same freon for years and years, people cannot withstand long periods of unrelenting overtime. The result as stressed in many studies is burnout – whereby an individual ceases to function even at a normal level. From my engineering days, this is the same as fatigue failure – no object on earth can withstand constant stresses without eventually failing due to material fatigue.

While working for The Gallup Organization, authors of How Full is Your Bucket (Rath, 2004) surveyed more than 4 million employees worldwide on the topic of workplace appreciation spanning 10000 business units across more than 30 industries. Their studies led them to discover that individuals who receive regular recognition and praise:

  • increase their individual productivity
  • are more likely to stay with their organization
  • receive higher loyalty and satisfaction scores from customers
  • have better safety records and fewer accidents on the job

Great recognition and praise can transform a workplace, the authors write. Their studies show that organizational leaders who share positive emotions have work groups with a more positive mood, enhanced job satisfaction, greater engagement, and improved group performance. (Roth, 2004)

Tuning your skills:

None of Zig Ziglar's Ten Commandments is difficult – yet the awareness of each item is important to successful project management. Tuning up your observational skills and consciously applying the principles is a pre-requisite to them becoming habitual. Some of the best project leaders are technically great but fail miserably because they cannot manage people. Rewards and recognition do not have to cost money – a verbal thank you or single page note is a small gesture that pays big communication and project rewards.

Summary Need for Effective Communication (Regular Tune-ups)

Carl Weinschenk (Weinschenk, 2003) wrote about the growing need for effective communication for Chief Information Officers (CIOs), but his message applies equally to all project team members for whom their ideas, concepts and especially requirements articulation are essential to building a high quality software product:

“The ability to express yourself grows in importance as you rise in the organization and your tasks become more conceptual and less hands-on. Somebody whose job is to deploy a WLAN or upgrade security may go weeks without speaking to a nonengineer on work-related topics; a CIO has to communicate with a variety of people whose jobs are not technical. Execs' resumes must demonstrate communication skills.”

As stated in the opening paragraphs, the key to software quality lies in getting the right requirements, and getting the requirements right. To do so requires solid and effective communication skills. The recommendations and steps outlined in this communication tune-up fits well within all improvement methods and techniques and serves as a reminder that what we say and how we say it can affect our project outcomes.

On occasion we've overheard statements on software development projects similar to: “software quality would be easy if we could only remove the people from the equation.” While the statement may be true, without people there would be no need for software let alone quality software. Once we can master the art and science of effective communication, we can be smarter about building better software in a faster, cheaper and higher quality way. Where can we go from here? After an automotive tune-up we take the car out for a test drive and if the tuneup was done properly, we immediately notice the smoother ride and easier shifting. Some of the tune-up won't be immediately noticed – in fact, their benefits come in the form of inconvenience avoidance – that is, the car will continue to operate efficiently for a longer period of time. Responsible driving means maximizing the benefits of the tune-up and easing into acceleration, careful turning, and avoiding bumps in the road ahead.

References

Baker, W. E., (1994) Networking smart – How to build relationshiopsrfor personal and organizational success,, R.R. Donnelly & Sons

Crosby, P. B, (1988) The eternally successful organization, the art of corporate wellness, McGraw-Hill.

Dekkers, C. & McQuaid, P., (2003, October) Maximizing project success: Give your communication skills a tune-up, Proceedings of the 13th annual International Conference on Software Quality, ASQ Software Division, Dallas, TX

DeMarco, T. & Lister T., (2003) Waltzing with bears: Managing risk on software projects, Dorset House Publishing.

Doc's Motorworks website http://www.docsmotorworks.com/tuneup.htm (page withrdrawn)

Doernhoefer, M. (June 1997) Object-oriented specification documentation: Building requirement specifications from OO models, Crosstalk, Retrieved from www.stsc.hill.af.mil/crosstalk/1997/06/object.asp

Edgar, J., (2002, August) as quoted by Free Press Staff Writer, Basic tune-up can boost classic car, Retrieved from http://www.freep.com/news/metro/dreamcruise/2002/clean13_20020813.htm

Gaffney, S,,(2004, July) Steven gaffney's bi-monthly advice: 7 critical tips for effective leadership [electronic newsletter] Retrieved from www.stevengaffney.com

IEEE: IEEE Guide to software requirements specifications. ANSI/IEEE Std. 830-1998

Insight, the Army Software Metrics Newsletter, Summer 2002 www.armysoftwaremetrics.org/insight.htm

Lerche Davis, J. (2003, May), Self-esteem: tied to others' opinions? Low self-esteem can be a normal reaction to disapproval”, Retrieved from http://cssvc.health.webmd.compuserve.com/content/Article/65/72826.htm

Morris, P. W. G. The management of projects. Ed. Thomas Telford. London, 1994.

Nelson, M., Clark, J. & Spurlock, M.A. (1998) Curing the software requirements and cost estimating blues. Software Technology Conference keynote address by Patricia Sanders, Director of Test, Systems Engineering and Evaluation, Office of the Under Secretary of Defense, Acquisition and Technology. www.dau.mil/pubs/pm/pmpdf99/nelsonnd.pdf

RoAne, S., (2000) How to work a room: The ultimate guite to savvy socializing in person and online, HarpersCollins Publishing.

SPICE: Software process improvement capability determination series of models developed by ISO's ISO/IEC JTC1 SC7 WG10, www.jtc1-sc7.

Standish Group, Unfinished voyages, A follow-up to the CHAOS report, 2003, Retrieved from http://www.standishgroup.com/sample_research/unfinished_voyages_1.php

Strauss, W. & Howe N. (1999) The fourth turning: An american prophecy in the 21st century,, Broadway Books.

Davis, J. L. (2003, May) Self-Esteem: Tied to Others' Opinions? Personality and social psychology bulletin, Retrieved from http://cssvc.health.webmd.compuserve.com/content/Article/65/72826.htm

Weinschenk, Carl, (2003) Execs' resumes must demonstrate communication skills, Retrieved from http://techrepublic.com.com/5100-6299_11-1057800.html

Ziglar, Z., (1998) Success for dummies, Foster City, CA: IDG Books Worldwide,.

Note: CMM and CMMI are registered trademarks and a service mark of the Software Engineering Institute, Carnegie Mellon University (www.sei.edu)

Author Biographies

Carol A. Dekkers is the President of Quality Plus Technologies, Inc. a management consulting firm specializing in IFPUG Certified Function Point training, software quality initiatives, measurement, and process improvement. She is a frequent presenter and instructor internationally at quality and measurement conferences. Ms. Dekkers is a Certified Management Consultant (CMC), a Certified Function Point Specialist (CFPS), a professional engineer (Canada) and an Information Systems Professional (ISP). She was the 1998/99 President of the International Function Point Users Group (IFPUG) Board of Directors, and is currently a project editor within the ISO Functional Size Measurement working group (ISO/IEC/JTC1/SC7 WG12). Recently ASQ's Quality Progress Journal (January 2000) included her as one of the 21 New Voices of Quality for the 21st Century. Carol also serves as a Regional Director for ASQ's Software Division, and as Vice-Chair of the Project Management Institute (PMI) Metrics SIG. She is a member of IEEE, ASQ, PMI, IFPUG, ICMCI, CIPS, and APEGGA. Visit her website at www.qualityplustech.com or contact Carol by email at dekkers@qualityplustech.com.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2004, Carol Dekkers
Originally published as a part of 2004 PMI Global Congress Proceedings – Anaheim, California

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.