The Hippy, The Artist and The Politician

If you ever do an MBA, you will find that two things appear a lot: simple matrix models (e.g. Porter’s Competitive Strategy matrix) and lists such as Maslow’s hierarchy of needs. This blog talks about another list I find useful in the workplace: McClelland’s Theory of Needs. The theory gives a convenient framework for assessing people in the workplace, what they want and how to motivate them.

The Essentials

Basically, McClelland’s theory states that people desire one of three things and their actions tend towards obtaining them. These three things are:

• Affiliation
• Achievement
• Power (personal and institutional)

Ten years ago, when I did the MBA, I was achievement motivated (with power coming a close second). This is probably still true. The test used to assess this is quite interesting; you are presented a series of pictures and asked to interpret the situation you see. The idea being you bring your own baggage to the pictures and this reveals your needs.

To highlight the three ‘desires’, I have chosen the Hippy, the Artist and the Politician.

The Hippy (Affiliation)

The Hippy seeks harmony and acceptance. They avoid confrontation and shy away from ‘constructive challenge’. A workplace of affiliation-motivated staff will go to lunch together, do activities together on the weekends and rarely argue or confront each other.

To keep the Hippy happy in the workplace, give them high levels of interaction with other people, and projects where they collaborate with others to achieve a common goal. A good way to reward the Hippy is through public praise showing appreciation and acceptance. To motivate the Hippy, tell them how much you will personally value their efforts in performing the task ahead. If the task makes you value them as a person, the Hippy will relish in it.

The Artist (Achievement)

The Artist craves to apply their skills to a problem and solve it to the best of their ability. They want unique challenges they can sink their teeth into and overcome. A workplace of achievement-motivated staff will solve the crossword/sudoku at lunchtime, invent problems to challenge each other and find creative pursuits outside of the office which allow them to use their skills to be productive.

To keep the Artist happy in the workplace, give them tough, but achievable goals. The reward for the Artist is the achievement itself. Motivating the Artist is all about designing the task so that it is unique, challenging and interesting. An unchallenged Artist is an unhappy Artist.

The Politician (Personal/Institutional Power)

The two forms of power here refer to a person’s desire to manipulate and control others (personal power) and being responsible to co-ordinate resources to achieve organisational goals (institutional power). We all know of the personal power Politicians in the office. Generally they are not liked but are left alone because they are ruthless. I do not have much issue with personal power Politicians. While you are useful to them, you are their best friend and when you are no use to them, they leave you alone. Stay out of their way and you are fine.

This being said I can think of nothing worse than an office full of personal Politicians. Personal Politicians would spend more time out-playing each other than getting anything done. An office of Institutional Politicians could work as long as some were willing to actually execute the plan, rather than just devise and co-ordinate it.

To keep a personal Politician happy, give them something to control, something which is theirs alone to manage. It does not have to be important or directly affect others as long as it allows them to exert control. The institutional Politician is happiest when they are managing resources to achieve an outcome. Unlike the Artist, they do not have to be the person executing the plan, as long as they direct it.

Rewarding the Politician involves giving them more influence. This may seem dangerous for the personal Politician but, as long as they realise you are the source of their power, you will ultimately still be in control.

For the personal Politician, motivating them involves demonstrating what is in it for them to do the task and, for the institutional Politician, how their efforts will benefit the collective group.

Conclusions

While no one is driven by just one ‘need’, my experience is people do tend to have a need which pulls them stronger than others. By understanding this need and, therefore, their perspective, you are in a better position to give them what they need to be happy in their work and be as productive as they can be. McClelland’s model gives a good framework to assist this understanding.

Dialog Lookup Values For Common Entities

One feature of dialogs is the ability to prompt the user for a record to interact with i.e. prompt for a lookup response.

The Reference Entity and Reference Field are two of the least intuitive features of CRM so I thought I would write an article on how they work and some good values to use for them.

How They Work

Essentially, the two fields are used to define a lookup which already exists in CRM so it can be presented to the user, during the dialog, and receive a value.

So, if you are wanting to capture, for example, a Contact record from the user, you could use the Primary Contact lookup (Reference Field) on the Account entity (Reference Entity).

This will allow the dialog to prompt the user for a Contact lookup so a Contact can be chosen.

Once this is explained, it actually makes a lot of sense or, at least, is quite easy to use.

Typical Values for the Common Entities

According to the Audit Settings, these are the Common Entities, with some suggested settings for the dialog:

• Account: Account-Parent Account
• Contact: Account-Primary Contact
• Goal: Goal-Parent Goal
• Goal Metric: Goal-Goal Metric
• Lead: Account-Originating Lead
• Marketing List: Create a custom lookup (see below)
• Product: Case-Product
• Quick Campaign: Use the Campaign/Quick Campaign composite lookup on Campaign Response-Parent Campaign (see below)
• Rollup Query: You can use Goal for a specific Rollup Query type, otherwise a custom lookup
• Sales Literature: Create a custom lookup
• Security Role: Create a custom lookup
• User: Any owner lookup will work for this

For a custom lookup, what I mean is creating a 1:N relationship of your choice and then using the lookup field which gets generated with the relationship. For example, we could make Contact a child of Marketing Lists and then use the resultant lookup field in our dialog to allow the user to select a Marketing List.

A composite lookup is a lookup which allows the user to select a record from more than one entity. So, in the example above, the Campaign Response-Parent Campaign lookup allows the user to select from either Campaigns or Quick Campaigns.

The Customer lookup is also a special, hard-coded lookup which allows the user to select either an Account or Contact. This can also be used in a dialog if an Account/Contact is required e.g. for the client associated to a Case.

Typical Values for Sales Entities

For the sales entities we have:

• Competitor: Custom lookup
• Invoice: Custom lookup
• Opportunity: Lead-Qualifying Opportunity
• Order: Invoice-Order
• Quote: Order-Quote

Typical Values for Marketing Entities

For the marketing entities we have:

• Campaign: Campaign Response-Parent Campaign (also allows the selection of a Quick Campaign) otherwise a custom lookup

Typical Values for Customer Service Entities

For the customer service entities we have:

• Article: Case-Knowledge Base Article
• Case: Custom lookup
• Contract: Case-Contract
• Service: Contact-Preferred Service

Conclusions

Once explained, the configuration of a lookup response for dialogs is not too difficult. With the above examples, most dialogs can be configured without the headache of having to trawl through CRM to find the right lookup for the job.

TFS For CRM Development Management

Sometimes on CRM projects you get asked to do things outside of your usual routine. On my latest project I am setting up Team Foundation Server (TFS) so the development and testing teams can use it to:

• Track the progress of a cycle of configuration, followed by a cycle of development
• Manage the development tasks for the modules they are creating
• Trace the individual business requirements against the development modules
• Track the testing of the business requirements to ensure they are met as the modules are completed
• Track issues discovered against the development modules for follow-up
• Review who is checking in code

Previously, I had only known TFS for source control but it turns out it has been extended in the last few versions to do a lot more. I am working with TFS 2010 but, I am reliably told, TFS 2013 goes even further to make TFS the one-stop shop for development management.

What Information Can We Capture?

TFS has a number of ‘entities’ to manage development. These are:

• Areas
• Iterations
• Work Items
  • User Stories
  • Tasks
  • Issues
  • Shared Steps
  • Test Cases

Areas are a bit like the Subject entity in CRM. The are used to categorize Work Items and are self-referential so an Area tree can be setup (this is done from the Team settings area of Visual Studio).

In my case I created Areas for:

• Deleted Items: There is no obvious way to delete Work Items, so I unlink them from everything and mark them with this Area
• Requirements: This is a category for all Work Items which define a business requirement of the system
• Development Modules: The self-contained modules being developed for the CRM system
• Development Tasks: The steps a developer will follow to complete a module

While I could make a hierarchy of these areas, I saw no benefit in my case and left them unlinked.

Iterations are the build cycles. In my case, I have two cycles: a configuration cycle and and development cycle. The only information we capture on the Iteration is its name and whether it is part of a hierarchy (like Areas, Iterations can be structured like a tree).

The Work Items are, in some ways similar to CRM Activities in that, while Activities are treated as a group in some ways e.g. when constructing queries, the sub-types also get individual treatment, specifically when storing information.

A User Story is something we are working to achieve with the development. So, for me, this covered two aspects: the development modules and the business requirements.

Here is the User Story form in TFS.

For my purposes the following fields were useful:

• Title: To describe the development module or business requirement
• Assigned To: To set the person building the module or the person responsible for testing the business requirement is met
• State: For specifying where the module/business requirement testing is up to
• Area: For classifying whether it is a development module or business requirement
• Iteration: For specifying which cycle the module will be developed in or the cycle the requirement will be met in
• Details: A broad description of the module or the details of the business requirement
• All Links: This is when we link the various records together, which we will cover later

Tasks are like their namesake in CRM; they are something to do. In my case these were perfect for listing the steps in the breakdown of work for each development module.

Here is a Task in TFS.

Again, we have the Title, Assigned To, State, Area, Iteration, Details and Links areas, as with User Stories, but we also have:

• Activity: which defines the kind of Task being done

• Start Date and Finish Date: To define when the Task is expected to be actioned
• Effort (Original Estimate, Remaining and Completed): To manage how the developer’s effort matches to the original estimates and to give an indication of how complete the Task is

Issues, not surprisingly, are for recording problems. In my case these are the bug reports, held against a development module for the developer to action, once testing has been performed. Here is the form.

This is similar to the User Story form and the fields are used in, essentially, the same way.

Shared Steps are common testing steps which can be used across multiple test processes. In my case, the testing of a business requirement required only the capture of a pass/fail with an Issue raised in the case of a failure so I did not use these.

Test Cases, surprisingly, I did not use. Mainly because, while it is possible to create a Test Case within TFS, it is not possible to create Test Case steps; these are created in Microsoft Test Manager (MTM), a separate product and automatically brought in to TFS. Given my simple test requirements, I avoided using Test Cases with the pass/fail being recorded via the Status of the business requirement.

Linking the Entities

In the case of Areas and Iterations, these have a 1:N relationship to Work Items. For the Work Items themselves, any Work Item can be linked to any other Work Item in a way similar to Connections in CRM. This means all manners of structures can be created in TFS. The key consideration in determining the right structure is working out what reports are likely to be generated from the system. In my case, the structure was like this:

So, for example in ‘Iteration 2’, the development iteration, we develop an SMS Module which meets the business requirements regarding the sending of SMS from the system. The tasks for the module are defined and, when the system is tested, issues are logged against the development module for the developer to action.

Within TFS, we now have a one-stop shop for the progress of development. We can open up the development module record and see all related information. By enforcing a policy of associating a Work Item to every code check-in (part of the team setup) we can also see the code being checked in from the development module record.

My Departure From the Norm

While a reasonably sensible structure, this does deviate from the ‘norm’. Generally, the development tasks come under the business requirement (User Story). For me, there were over 1,000 business requirements so this meant a lot of bookkeeping for minimal gain. The only consequence of my approach is some of the out of the box reports, which assume a certain structure, will not work quite as expected.

Reporting

There are three main approaches to reporting with TFS:

• Queries
• Excel
• SSRS

Queries are quite easy to set up and work very much like Advanced Find queries. You are limited to the one entity but, for my purposes, it was sufficient.

From Visual Studio, you can also export queries to Excel. This option also allows for republishing back to TFS, which is great for mass-editing.

Finally, is those are insufficient, SSRS reports can be written as the information in TFS can be queried via SQL.

Conclusions

If your development team is already using TFS for source control, consider also using it for development management. The developers can remain in the products they are used to (Visual Studio and TFS) and the project manager can gain visibility of progress. Also, if you have geographically separate groups developing, this provides a common place to review progress.

Finally, I would like to thank the ‘Davids’ (David Watson and David Jansen) of Microsoft for walking me through TFS. Without their patience I would have have half the knowledge and twice the frustration with the product and their generosity of time is greatly appreciated.