Tag: Requirements

Roses, Stars and the Sun

Medieval England. War of the Roses. On April 13^th, 1471 Yorkist troops, under the command of the king, Edward IV, and Lancastrian forces led by Richard Neville, 16th Earl of Warwick and John de Vere, 13th Earl of Oxford met near the town of Barnet some twelve miles North of London. At four o’clock in the morning on April 14^th the soldiers of both armies were awakened and started preparing for the decisive battle. Warwick’s army heavily outnumbered Edward’s, although sources differ on exact numbers. However, according to some historians, Lancastrian strength ranged from 10,000 to 30,000 men, with 7,000 to 15,000 on the Yorkist side.

The major problem that both armies had to deal with was a heavy fog that covered the entire battlefield thus making any kind of monitoring or communications with their units somewhat problematic.

Medieval battles have never been known for their orderliness and organization; however because of the heavy fog, the confusion that existed on the field on that particular day dwarfed anything that was seen in military campaigns before and since that memorable day. In this mayhem at one point of time John de Vere’s forces ended up behind their allies, a part of Lancastrian force led by Warwick’s younger brother John Neville. Neville’s regiments for reasons to be explained a bit later mistook their comrades-in-arms for enemies – Edward’s reserve forces – and unleashed a volley of arrows on them. De Vere, in his turn quite logically assumed treachery and attacked Neville’s troops … The cries of treason quickly spread throughout the entire battlefield and as the fog started to dissipate, Edward saw the Lancastrian centre in disarray and sent in his reserves, hastening its collapse. One by one, first John Neville, then de Vere and finally Warwick were killed by Yorkists.

Some historians claim that as many as 6,500 Lancastrians perished in that engagement – a mind-boggling number of casualties by the 15^th century standards. As for Edward, he retained his crown and ruled England for the next twelve years.

We now arrive at the most curious part of this story: how was it possible for Neville’s forces to mistake their allies for their enemies? The answer lies in the fact that 15^th century armies did not have uniforms; the only way to tell enemy from foe was by the heraldic banners each troop carried into the battle. And here is the kicker: Edward’s coat of arms contained a depiction of the sun with several wavy rays – “Sun in Splendour”, while John de Vere, had an “Éstoile” (star with six wavy rays) on his crest. Unfortunately the bulk of John Neville’s regiment consisted of illiterate peasants who had no training in heraldry whatsoever; at the time this discipline was typically reserved for someone belonging to the higher echelons of British society. It is not surprising, therefore that they confused these heraldic signs and reported back to Neville that “the enemy is behind us!”

The project management lesson of this story is that when running projects, especially large and complicated ones, no little detail of the project scope can be overlooked. Ignoring these “little and insignificant” details can lead to disastrous results like the one mentioned in the story above. Accordingly I would like to dedicate this article to the problems and issues of the detailed scope definition that has been somewhat overlooked in the current project management science.

More Detailed Scope Definition

In a previous article titled “Kick-Starting Your Projects – What Should You Know About Defining Scope?” we have already discussed the elicitation of high-level scope requirements that would probably appear in the Project Charter or some other auxiliary scope document. At this stage however we are zeroing-in on the next step, the following iteration of scope definition that happens some time after the sign-off of the project charter but before the technical team members start working on the final designs, blueprints and bills of materials.

Eliciting Detailed Scope: Who Should You Talk To?

A question that gets asked frequently, especially on large and complicated projects is: “Who should I include in scope discussions?” This is a very complicated matter and a good number of projects I have known suffered setbacks in the form of cost overruns and missed deadlines because the right group of people (or even single person) were not consulted properly at the scope definition stage.

The first collective group of primary stakeholders are the clients (aka sponsor), customers and the future users of the product or service you are trying to build.

Clients have the final say in the product scope discussions about what the product does, how it does it and how sophisticated or simple it should be because they are the ones financing the project.

Customers are also important because they (hopefully!) will buy and pay for your product. Alternatively they may ignore it and decide to buy the competitor’s product. Therefore it is very important that you understand their real needs.

End users could be a different group from customers; i.e. purchasing can be done by one group of people and actual usage by another (think of millions of parents buying video games for their kids during the Christmas season). On a more serious note, it is typically the users of the product or service who possess the deep knowledge and expertise in the area to provide the project manager with real detailed requirements.

Other groups of stakeholders can include company management, subject matter experts and consultants, project team members, inspectors, legal experts, public opinion, government and last, but definitely not the least, adjacent departments within the organization.

Why Do We Neglect The Stakeholders?

I have seen it happen on numerous occasions: the project manager and his team of technical experts deciding either independently or under pressure from their management to ignore one or more stakeholder groups in their detailed scope definition efforts.

Exhibit 1

Some of the excuses mentioned by these teams were:

• “We are afraid the stakeholder will find out too much about the problems we are having and the mistakes we made, rather than seek their help in overcoming the difficulties”
• “We are too busy to take time out to communicate and coordinate with our stakeholders”
• “We think/pretend it is harder when we involve the stakeholder”
• “We think we can do it without the stakeholder”
• “We believe stakeholder involvement costs too much money and time”
• “There are personality conflicts with key stakeholders”
• “Our own management won’t let us”
• “We are already late with some of our deliverables! Talking to the stakeholder will waste more of a valuable project time”

Note: in this particular discussion stakeholders include clients, customers, end-users, company management, subject matter experts, etc.

Project managers should be aware of these “excuses” to ignore the voice of the stakeholder and must be ready to defend their decisions to invest the necessary time and effort into building proper project scope. The value of investment in requirements can be clearly demonstrated by the study conducted by Barry Boehm to determine the relative costs of fixing an error at various stages of the project (see Exhibit 1). The question I have been consistently asking my overly hasty team members, managers and other project stakeholders:

“Would you like to spend one hour discussing the scope with me now or would you rather spend between forty to one thousand man-hours fixing our scope omissions and defects closer to the end of the project?”

Types of Requirements

One of the popular ways of grouping requirements is by dividing them in conscious, unconscious and undreamed-of requirements (see Exhibit 2). Conscious requirements are typically the easiest to trawl for. These scope items are typically uppermost in customers’ minds, they are almost always indicative of something your customer is trying to create or improve. For example, a small business owner who is trying to increase her revenue stream by selling products on the Internet will undoubtedly mention a website with product catalogue, shopping baskets and ability to make payments using most popular credit cards. Therefore, it is very likely that these requirements would be the first ones mentioned by the stakeholders during one-on-one interviews with the project manager making such requirements fairly easy to catch.

On the other hand, unconscious requirements are a bit more difficult to extract because they are so common and familiar to the stakeholder that he frequently fails to mention them, assuming that everyone is aware them. Again, using to the small business owner example, including value-added tax into the final price of the product sold via Internet could be considered a common knowledge by the business owner, and yet a web developer may not possess sufficient understanding of accounting to add this requirement to the scope of the project. Unconscious requirements are one of the most difficult to elicit since they are frequently go unmentioned by the stakeholders. Only inquisitive and thoughtful questioning and follow up walkthroughs can unearth all of the unconscious scope items.

Undreamed-of scope items are the things that could be very useful to the customer, but for whatever reason – typically lack of technical expertise – she is not aware of their existence. Once more, returning to the website example – the small business owner may not be aware that all credit card-related information must be encrypted and protected according to the industry standards. The burden of informing him about this regulation and thus adding an extra requirement lies on the project manager’s shoulders.

Exhibit 2

Requirement Type	Explanation
Conscious Requirements	Uppermost in customers’ minds indicative of something your customer is trying to create or improve
Unconscious Requirements	So common and familiar to the stakeholder that he frequently fails to mention them
Undreamed-of Requirements	Things that could be very useful to the customer, but for whatever reason – typically lack of technical expertise – she is not aware of their existence

How to Ask the Right Questions?

When developing a detailed scope document it is very important to ask the right questions to elicit all of the requirements from the customers. The problems of scope definition and documentation could be rooted in unspecified information, unspecified comparison, generalization or universal qualifier types of statements.

Unspecified Information – very frequently these statements are somewhat counterintuitive to the average person, since we tend to ignore or just blindly accept the underlying assumptions buried in them. For example, a simple statement “We get the sales reports” should right away raise at least the following questions from an experienced project manager (see Exhibit 3 for more examples):

• Who are “we”
• What do you mean by “get”?
• What is a “sales report”?

Unspecified Comparison – when the stakeholder uses words like “better”, “faster”, etc. The questions that should right away start popping up in the project manager’s head once he hears a statement like “The new container terminal should be better” are:

• “Better” compared to what?
• “Better” in which way?
• Who decided that it should be better?

Generalization – typically occurs when you hear words like “must” or “can’t”. For instance, the customer may state something to the effect of, “The new store must be located at the intersection of two major streets in the Oakmount neighbourhood”. The questions asked by the project manager should be:

• Why must you do it specifically that way? Why should the store be located at the intersection? Why major streets? If you are looking for high-traffic areas, have you considered other locations, like malls or shopping plazas?
• What happens if you can’t find a space for rent at the intersection of two major roads? Will you abandon the idea of opening the new store? Will you postpone it? What kind of drop in revenue are you anticipating?

Exhibit 3

Type of Statement	Sample Statement	Sample Questions
Unspecified Information	“We get the sales reports”	“Is it just you or your entire department?” “Or just specific employees within your team?” “Are other departments privy to these reports?” “If yes, then who in other departments gets them?”   “What do you mean by “get”?” “Are the reports printed out and mailed to you or are they faxed?” “Do you receive them by e-mail?” “In what format?” “Do you have a software package that produces them automatically?”   What is a sales report? What kind of information is contained there? Do you just have one type of report or several?
Unspecified Comparison	“The new container terminal should be better”	“Better compared to what?” “To the existing terminals at your port or your competitors?” “Or the best in the world?”   “Better in which way?” “In terms of square footage, overall container capacity, logistics, usage of computer technologies, security?”   “Who decided that it should be better?” “What is the reasoning behind this decision to increase capacity, improve logistics or security?”
Generalization	“The new store must be located at the intersection of two major streets in the Oakmount neighbourhood”	“Why must you do it specifically that way? Why should the store be located at the intersection?” “Why major streets?” “If you are looking for high-traffic areas, have you considered other locations, like malls or shopping plazas?”   “What happens if you can’t find a space for rent at the intersection of two major roads?” “Will you abandon the idea of opening the new store?” “Will you postpone it?” “What kind of drop in revenue are you anticipating?”
Universal Qualifiers	“The terminal gate shall always be operated from the main control room”	“Is it really never or does it happen sometimes?”   “Is it really always or are there some exceptions?” “What happens if the main control room is blocked?” “What should the employees do in case of emergency (e.g. fire)?”

Universal Qualifiers – you come across them in statements containing words like “never” or “always”. The questions one should be asking in this case are:

• Is it really never or does it happen sometimes?
• Is it really always or are there some exceptions?

Which Technique is the Best?

There has been some confusion with respect to which scope definition techniques should be used on various types of projects. In IT and software development we more or less know that functional and non-functional requirements and full-scale use cases typically fall into the category of larger, traditional waterfall projects. User stories tend to get utilized on more agile, smaller engagements. Despite that, I have been questioned by a large number of my colleagues and students from non-IT industries regarding the validity of various requirements trawling techniques on different kinds of projects.

In order to answer these questions, it is useful to divide the projects into three broad categories:

• Rabbit projects are small and fairly simple engagements with a co-located, tightly knit team and a small number of customers who are willing to invest a lot of their time in the scope definition stage. The techniques that work well on such projects are brainstorming and creativity workshops because of the proximity of the participants and their willingness to participate in scope definition process.
• Elephant projects are, as a rule, very large and sophisticated endeavours with budgets in tens or hundreds of millions of dollars, like the launch of a space shuttle, development of a new type of passenger airplane or construction of a new port terminal. Project teams on such projects are large and very likely to be spread out at several locations – sometimes on different continents separated by thousands of miles. There are a lot of stakeholders who more often than not do not have much time at their disposal to invest in requirements trawling. As a result apprenticing, i.e. spending time watching the stakeholders perform their daily duties, especially in order to understand business processes can be of great value.
• Horse projects are the “something-in-between” endeavours that retain the characteristics of both Rabbit and Elephant projects. They could be, for example, of medium size but have a distributed group of stakeholders. My personal observations actually confirm that a vast percentage of projects will most likely fall into the Horse category since it is very difficult to find a project that possesses all of the characteristics of the Rabbit or Elephant. As a result of such a blend, most of the techniques mentioned in the table rate as “great” or “satisfactory” fits for the Horse projects.

Exhibit 4

Note: Three stars implies great fit, two stars – adequate fit, one star – bad fit

The interesting aspect of Exhibit 4 is that apparently techniques like interviewing and searching for the essence (i.e. trying to identify the real problem behind every scope item) are absolutely universal, no matter what project you are working on.

What are the Criteria for Quality Scope Items?

So, now that your scope document is complete what guidelines should you follow to ensure that requirements recorded are of good quality and can be validated by the project stakeholders while being easily understood by all the technical team members – programmer, architects, engineers, etc. Below, in Exhibit 5, you will find a list of attributes of good project requirements

Exhibit 5

Attribute	Explanation
Complete	Has all the details of every scope item been covered? (e.g. all possible scenarios, alternatives and exceptions)
Consistent	Can the requirement be met without conflicting with other requirements? If not, the requirement should be removed or revised
Traceable	Is the origin of the detailed scope item known? Can it be traced directly to the high-level product or service feature recorded in the project charter?
Concise	Is the requirement stated simply and clearly? Can it be easily understood by both the customers and technical team members?
Design Free	The detailed scope item should be stating what must be done without indicating how. Did we make sure that the technical aspects of the detailed product design are left to the technical experts?
Standard Constructs	Requirements are stated as imperative needs using “shall”. Avoid using words “should” or “may”; they create a sense of false priorities.
Unique Identifier	Has the detailed scope item been uniquely identified? For example, “R1”, “R2”, “R3”, etc.
Prioritized	Has the requirement been assigned a priority relative to other requirements in the document? For example “Must Have”, “Should Have” and “Nice To Have”
Rationale for each requirement	Has the rationale for each scope item been clearly identified and agreed upon by all the relevant stakeholders? In other words, “do we really need this?”

Introducing Measurability

Let me start this section of the article with the following example. Pretend that you are a custom furniture builder and a client shows up at you workshop citing that he needs a dinner table “of an adequate size for his family”. Without any further discussions and requirements elicitation how easy do you think it would be to fulfill this order? Compare this requirement with the following one, “The table should be 6 feet long, 4 feet wide and 3 feet high”. Do you think this request is easier to implement?

If the above exercise was a bit too easy, let’s complicate things. How about this scope item:

“The new container terminal shall be of a sufficient square footage to accommodate load requirements in peak times”

I can’t speak for the reader’s experiences, but I have come across statements similar to the one just mentioned on numerous occasions while working as a process improvement consultant and peer reviewer. Interestingly enough, for some reason most of the people I have questioned find the statement about the terminal much more “digestible” than the statement about the dinner table. I am not sure why this happens (this could probably be explained much better by psychologists, than by a project management expert) but it appears that the concept of a dinner table is somewhat more tangible and familiar to the average person than an enormous area designed to house the containers. Maybe we tend to be more fastidious when it comes to familiar, palpable objects and concepts?

Now, compare the old terminal requirement to the following statement:

“The new container terminal shall have a capacity of at least 600,000 TEUs (twenty-foot equivalent units)”

If you were an architect or an engineer, which requirement do you think would have been more helpful if you were about to start working on a terminal blueprint?

Introducing measurability to scope items is one of the key factors in improving the quality of requirements and avoiding future misunderstandings (i.e. rework and budget overruns) as the project progresses from the planning to the execution and closeout stages.

Having said that, imposing measurability on scope is one of the most stressful exercises the project manager can go through during the scoping stage. Firstly one has to discover all of the words and phrases in the scope definition that need to be made measurable – this, by the way, is typically the easier of two steps. Secondly, the project manager has to sit down with the stakeholders and compel them to provide real numbers to replace vague wordings in the scope statements. Customers are usually reluctant to do that fairly early in the project because they either don’t know the measures required and/or are unwilling to accept the responsibility for providing them. In other words, their line of thought can go something like this, “what happens if I claim 600,000 TEUs and it turns out that in the peak times the demand reaches 850,000 TEUs?”

Also, providing answers to such questions typically require a lot of additional work and research which, in my experience, has sometimes been discouraged by senior management as “wasting time” or “delaying the start of an important project”.

How does one impose measurability on scope items? One of the easiest ways of doing that is by asking the following question:

“What would you consider to be a failure to meet this requirement?”

Let’s examine this method with an example. This conversation took place between me and a project manager working for a very large retail chain. He was responsible for one of the multiple “New Store Opening” projects and I was assigned to peer review his project documentation.

Me: “You need to impose some kind of measurability on your deliverables”

PM: “Our deliverables cannot have measurability associated with them. It is all-or-nothing approach. For example, if the store is supposed to have thirty point-of-sale (POS) stations, it should have all thirty stations installed and working for the opening!”

Me: “OK, but what happens if twenty nine out of thirty stations are working and one is defective? Do you think the company will say “no” to hundreds of thousands of dollars in revenue and postpone the opening of the store by even one day?”

PM: “Well in this case, obviously we will still go ahead with the opening”

Me: “And if twenty eight out of thirty stations are working?”

PM: “We would still go ahead!”

Me: “And what happens if only one out of thirty POS stations is working and the remaining twenty nine are broken?”

PM: “Well, of course we will have to postpone the opening of the store then!”

Me: “Here is what you need to do; talk to the customer and try to determine the threshold for the number of non-working POS stations. That number is you measurability parameter!”

How Do You Know When to Stop?

The caveats of not spending enough time defining the detailed scope of the project have been discussed in project management literature a lot and have also been confirmed by numerous studies by various researches including Standish Group (Chaos Report), Project Management Institute (PMI) and others. However a question diametrically opposed to the issue above is, “how does one know when he is done with building the scope definition?” Below you will find some of the indicators that it is time to wrap up the requirements stage of the project and move on to the final stages of the planning phase:

• The stakeholders can’t think of any other requirements. You notice that the stakeholders can’t think of any scope items no matter how many different types of questions you are asking
• The stakeholders repeat issues that have already been covered. You discover that the conversation starts going in circles and the same requirements get mentioned again and again
• The stakeholders request the requirements that are all out of scope. The Project Charter should have listed all of the high-level features; if the scope was limited to just a three-bedroom home, the requests for pool and landscaped yard should be out of scope.
• Newly proposed requirements are all low priority. The stakeholders keep mentioning scope items to include in the project but agree that these are low-priority items
• The users are proposing features that should be included in one of the next phases. You notice that the conversations with the stakeholders start drifting towards the future phases rather than current “release” of the project

Article Summary

When selecting the sources of project scope make sure to consider all relevant people, especially your clients, customers and future users of the product. Having said that, it is imperative to at least inquire if other stakeholder groups, like your company management, subject matter experts, project team members, company lawyers, and the “adjacent” departments within the organization have anything to say about the project scope.

There could be some pressure from your clients, your project team or even from your managers to “speed things up” and “avoid wasting time” by forgoing conversations with some of the stakeholders. Avoid such shortcuts at all costs! Always remember that one-dollar mistake or omission made during the requirements stage can become a thousand dollar defect at the end of the project.

Keep in mind the types of requirements that exist and make an extra effort to capture the “unconscious” requirements, since they frequently go unmentioned by the customer.

Employ the entire array of various kinds of questions at your disposal. It will take some time to know which question should be asked at what time, but eventually it will become your second nature. Also, don’t be afraid to ask “politically incorrect” questions like “Why do you think this way is better than the others?” or “When you say ‘never’ do you really mean ‘never’, or are there some exceptions?”

Know what requirements trawling techniques are appropriate for the type of project you are working on. Also keep in mind that you can never go wrong with one-on-one interviews and trying to find the problem first rather than blindly accepting the solution imposed by the customer. This technique is known as “the search for the essence.”

When documenting, and especially when reviewing your scope documents, remember the quality attributes of good requirements and the concept of measurability.

Bibliography:

1. “Software Requirements, Second Edition (Pro-Best Practices)” by Karl E. Wiegers
2. “Effective Requirements Practices” (Addison-Wesley Information Technology Series) by Ralph R. Young
3. “Exploring Requirements: Quality Before Design” by Donald C. Gause and Gerald M. Weinberg
4. “Requirements by Collaboration: Workshops for Defining Needs” by Ellen Gottesdiener (Kindle Edition – Feb 17, 2009)
5. Mastering the Requirements Process (2nd Edition) (Hardcover) by Suzanne Robertson and James C. Robertson
6. “Project Management Body of Knowledge (PMBOK)” by Project Management Institute (PMI)
7. Carpenter, Christine (2002) [1997]. The Wars of the Roses: Politics and the Constitution in England, c. 1437-1509. Cambridge Medieval Textbooks. New York: Cambridge University Press. ISBN 0-52131-874-2
8. Hicks, Michael (1995). “The Sources”. in Pollard, Anthony. The Wars of the Roses. Problems in Focus. London: MacMillan Press. ISBN 0-333-60166-1
9. Ross, Charles (1999) [1981]. Richard III. Yale English Monarchs. New Haven, Connecticut; and London: Yale University Press. ISBN 0-30007-979-6

---

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting, is an internationally acclaimed expert in the areas of project/portfolio management, scope definition, requirements analysis, process improvement and corporate training. Mr. Moustafaev is author of “Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management” (released by J. Ross Publishing in September 2010). He is also the author of various project management and business analysis webinars delivered in partnership with Project Times:

•   Why and How Should You Manage Scope and Customer Expectations?
•   Are We Supposed To Negotiate On Projects?
•   Top Ten Things You (Probably) Did Not Know About Estimation

In addition to teaching a highly acclaimed “Project Management Essentials” course at British Columbia Institute of Technology, Mr. Moustafaev also offers the following corporate seminars through his company:

“Practical Portfolio Management – Selecting & Managing The Right Projects”
“Successful Hands-On Management of IT and Software Projects” 
“Successful Hands-On Management of Modern-Day Projects” 
“From Waterfall to Agile – Practical Requirements Engineering”  

For further information, please contact: Mr. Moustafaev Phone: 778-995-4396 

E-mail::[email protected]  Website: www.thinktankconsulting.ca

The Technical Support Project

Now that you have a new and improved technical support team in place, you need to let people know. This includes departments within your company and external customers, both of whom need different types of marketing. This article will outline some ideas on how to spread the good word.

Where to Start

Have you ever had any luck telling someone at your company who doesn’t report to you what to do? Me neither. So what you need to do is sell it to them. This is not a one-time deal. You are looking to ingrain deep-seated changes and repeated transactions. That is the realm of marketing.

Changing Perceptions

Have you ever been served a plate of food that looked exactly like the picture on the commercial? Did you lose that weight like the health club promised? Were you able to get those stubborn stains out like it says on the bottle of cleaner you bought? That’s marketing.

You have to talk about the ideal case, the goal. Don’t shoot too high, using words like “guarantee” or “perfect.” Those words will come back to bite you. Also avoid shooting too low, using phrases like “if we are lucky.” That kind of attitude will undermine you right from the start. Rather, the perception that you need to set goes something like this:

“We have made some major changes. We are now better organized and better trained. We are monitoring and measuring ourselves to ensure that we consistently perform at a high level. You can trust us.”

Internal Marketing

You are going to need to market your team to the rest of your company before you try it with external customers. You will also want to involve other departments in your external customer marketing effort. You do, however, have a small window of time to accomplish this. If the external customers discover the new technical support system for themselves, it will lose some of the impact and you will get less credit for it.

Focus on the benefits each department will receive from your improved support system. When you are talking to salespeople, talk about salespeople. When you are talking to developers, talk about developers. When you are talking to accounting, talk about accountants.

1. Sales:

Salespeople are focused on sales, so you need to explain your team in terms of how it will help them close more sales. For example, you can tell them that they will be spending less time on the phone troubleshooting problems. They will also be able to call existing customers and ask for more business more easily. There will not be a large support problem standing in the way of customer satisfaction and developing the relationship further.

You need to provide Sales with both a new support transition script and a process for turning support cases over to you. The script can be fairly simple: “Yes sir, I understand that this issue is important to you. We have just spent a lot of time revamping our technical support system, and the team is much faster at figuring out solutions to problems than I am. They really care about fixing problems for you, so I trust them to take care of this.” You will have to determine which process will work best in your company. My recommendation is that you keep it simple. If you give the salespeople a checklist of information to gather, then they won’t bother. An email to the helpdesk with the customer’s name is perfect. If they can give you some indication of the type/severity of the problem, that is even better. You can also ask them to call you personally so that you can take down the information and create the case yourself.

2. Marketing

Marketing lives on happy reference-giving customers, so they will be glad to follow behind you to dig for quotes and references. It is important for the company that you help them to do that. Automating customer satisfaction surveys, for example, will be very useful.

Marketing feeds sales. Those quotes and reference customers are your long-term marketing program with the salespeople, helping you reinforce their new behavior. Don’t you just love it when a plan comes together? I hate buzzwords, but that is synergy.

3. Accounting

The new technical support system will also provide support cost data that can be allocated to each specific customer. Right now, the accountants are probably just spreading the costs of technical support across each customer based upon the amount that the customer has paid. If they can get data from you on how much technical support time each customer actually spends, then they can account those costs in a more accurate way. Such a level of understanding of your costs per customer is a tremendously powerful profit-maximizing tool. Upper management and product planning can use this data to target products to more profitable segments of customers. You can use it to argue for raising the support billings on the least profitable segments of customers.

Your accounting people might not see it at first, but the data about how much time you spend on each customer also helps them get the invoices paid. Customers who are using a lot of support time are clearly using the service, meaning they have no choice but to pay the full invoice price. The few who do not pay on time can be influenced by collection calls that threaten to cut off their technical support. Customers who are not using much technical support time, however, will likely need additional marketing about the benefits. You can also consider giving them discounts.

4. Development

You will need to engage the development team if you plan to hire your own developer. The development manager might react skeptically, but you can prepare for your conversation beforehand by gathering some data about how much time the developers spend working on bug fixes. Make notes, and take those notes to lunch with you. You need to sell this to the manager in terms of fewer interruptions and fewer headaches.

It is important to get the development manager on board with your plan because you will need his/her help. The manager must be willing to interview your candidates, train your new support developer on the code base and the source code control tools and invite your developer to meetings. You can’t force that, so gently suggest it after outlining how having a developer in support will benefit the development team and the company at large.

External Marketing

The sales and marketing teams will do most of the work for you on this. They may not run a full marketing campaign about how support is no longer terrible, but they do have a ton of automated messages and informal scripts that they can insert little announcements into.

The most important script is the one mentioned above for the salespeople to use when a customer confronts them with a problem. That personal recommendation is worth more than all of the rest of this marketing combined. You won’t get that personal recommendation very often though, and certainly not to all of the contacts at every customer. You other opportunities to fill in the gaps.

Your company probably already has all of these customer communications going:

• newsletter
• automated emails to website visitors and new customers
• cover letters with invoices

Ask the sales and marketing teams to include a recommendation of the new technical support system in some or all of those communications. Trust them to find the right locations and messaging.

You communicate with customers too, so take advantage of that. When someone opens a case in your helpdesk they should get an automatic email confirmation. Personalize it. Here is what I wrote for our helpdesk:

“Dear ________,

We have received your cry for help. We have logged it in our helpdesk under this case number: #########

Our support ninjas monitor the helpdesk from 7am to 6pm (Central US time), Monday through Friday. They sneak in some other times, but we can’t make any promises about that.

A real person will read this case within two hours (during the times listed above). We triage and deal with critical issues first. So if your payroll is threatened or your site is down you should expect to hear from us soon. And we try to reply to all problems that get to us before 4:00pm on the same business day.

You can reply to this email to update your case. Or you can call us at 800-755-9878 ext 2 (US) or 512-834-8888 ext 2 (everywhere else).”

The internal response to that message was near mutiny from the salespeople, and yes, we have had a handful of negative reactions from customers. On the other hand, we have had hundreds of positive reactions from customers:

“I love it. I’m glad I’m getting help from a real person instead of some software system.”

“Ninjas save the day again. You guys rock!”

Clearly I won. I take great personal pride from that, even though I am planning on rewriting it. I’m thinking that the next version will be in free verse.

Feedback

The support team members need to follow up with the clients. They need to find out if the solution worked. They need to ask the question in such a way that the natural response from the client will be an honest one and, hopefully, a complimentary one. The question should be something like this: “Did the solution I sent over work out for you? Is there anything else I can help you with?”

Assuming that the solution did work, the natural response to this will be complimentary. Sometimes it will even be quotable.

And sometimes the answer will be negative, and we will know that the problem is still unresolved. In those cases we just have to keep digging until we get it right and get to the compliment.

There are three great reasons to go the extra mile to provide great service and receive compliments. Firstly, it really does help the technical support staff to hear it. You can’t keep good technical support people for long if they aren’t getting some validation. Secondly, if the customer can say something nice about you today, that customer will have a positive attitude toward you tomorrow. They are significantly more likely to say something nice about you to someone else if they have already said it to you. That kind of word-of-mouth recommendation marketing cannot be bought. Finally, someone who is willing to compliment you directly is more willing to serve as a reference or provide a quote for your marketing efforts.

When you have transformed your technical support team, you will have done something truly spectacular. Good luck with it. Drop me a note and share your success stories.

---

Randy Miller has 11 years of customer-focused experience in sales and services delivery. Prior to joining Journyx in 1999 as the first Timesheet-specific sales rep, Randy spent five years in the Corporate Sales and Retail Management divisions of leading electronics retailer CompUSA. Since then Randy has held many different positions at Journyx, including Sales Engineer, Trainer, Consultant, Product Manager, Support Team Manager, and Implementation Manager for Enterprise Accounts. Randy has personally managed development and implementation efforts for many of the company’s largest customers and is a co-holder of several Journyx patents. Randy was named Director of Services in 2005. Randy can be reached at [email protected].

The support team members need to follow up with the clients. They need to find out if the solution worked. They need to ask the question in such a way that the natural response from the client will be an honest one and, hopefully, a complimentary one. The question should be something like this: “Did the solution I sent over work out for you? Is there anything else I can help you with?”

Assuming that the solution did work, the natural response to this will be complimentary. Sometimes it will even be quotable.

And sometimes the answer will be negative, and we will know that the problem is still unresolved. In those cases we just have to keep digging until we get it right and get to the compliment.

I had the pleasure to be a guest lecturer recently for a project management fundamentals course at Trent University in Peterborough, Ontario. While I’ve lectured in this way many times over the years for many different institutions, I was struck by the unique approach that this course used for teaching the project management basics.

Most project management courses use PMI’s Guide to the Project Management Body of Knowledge as both a text and a framework for teaching the subject. Classes are often divided along the chapters (knowledge areas) in the PMBoK Guide and students are taught a typical, sequential project management process (a.k.a. “waterfall method”) for implementing the tools and practices described in the book.

What was different about the Trent University teaching model was that they used two main textbooks: the PMBoK Guide (as expected) and a book on agile project management. The professor, Peter Northrop, explained that he wanted to give “a balanced perspective on two prevailing views of project management.” When I dug a bit deeper into this, he noted that in past years, computer science students (the primary audience for this course, although business students can also count the credit) who were taught a waterfall model for software development rarely completed the end-of-year assignments, often getting caught up in the paperwork side of their project rather than completing the deliverables. With the introduction of agile project management training, more projects are now getting completed, though with some noted resistance among those who still want to teach and use a more traditional, waterfall-based model.

Students were correctly taught that the PMBoK Guide describes a menu of processes and tools that one may want to use on a given project. There is no “PMBoK Method” prescribed by PMI; in fact, they don’t yet publish a project management methodology at all. When building their project plans, students are encouraged to select from the practices described in the PMBoK Guide to build sound project management approaches. Being given an understanding of agile project management right from the start (remember that this is a PM fundamentals course) means that students are often choosing iterative and incremental development models, with more of the agile management techniques. They see that these agile management techniques are not in conflict with the PMBoK Guide (in fact, many are described in that book) and they feel confident in adopting the processes and tools that make the most sense for their own projects.

I was amazed to see this teaching approach being implemented (and succeeding) with the students. Agile project management is usually considered to be an intermediate or advanced topic, not something that is taught to beginners until after they have learned the basics. Not that I thought that it wouldn’t work (after all, it is the holy grail of project management teaching, in my opinion) but rather that the approach was so innovative and that it was being pioneered at a university – the last place that I expected to see that kind of project management training innovation.

Giving students the understanding of a range of project management approaches and tools or process options builds more flexible managers who likely will be more able to adapt to various work environments when they are done school and entering the workforce. In addition, they more likely will have the confidence to adapt standard methods to deal with the unique characteristics of their projects. It takes a good understanding of a method to be able to modify it, and most managers don’t have the confidence or the knowledge to do so, resulting in the deployment of the full method on every project. These graduating students will be less likely to fall into that trap.

In my mind, this project management fundamentals course should be considered a model for the redevelopment of many of our existing project management training offerings. Recent studies in Dr. Dobb’s Journal show that agile management techniques are now being used in more than two-thirds of organizations and a healthy percentage of the remainder are considering trying out the agile approaches. Agile management is not a fad; it traces its roots back to the iterative incremental development techniques used for large scale software and systems development projects starting in the 1950s. It is time that mainstream project management training organizations realize this trend towards adopting agile techniques and start teaching them to their students. Heck, even the latest version of the PMBoK Guide finally at least mentions agile. If PMI is finally recognizing the trend, then perhaps there is hope that we will soon have more project managers trained with a broader set of tools, and the confidence to challenge assumptions in the quest to optimize the delivery of their own projects.