Monthly Archives: May 2013

Flip the Funnel

flip the funnel

Here is a book that I’m reading as part of my latest MBA course, this one on the topic of Business to Business (B2B) Marketing. I’m only a couple of chapters in but pretty impressed with what I’m seeing so far – and I don’t impress easily.

Basically, as you’ve probably guessed from the title, it’s taking some of the tried and true pillars of marketing and turning them upside down, literally. The author is making a case for how we’d be better off taking the typical marketing ‘funnel’ – where the a large number of leads that we’ve invested in advertising to eventually give way to hopefully at least a few conversions at the narrow end of the funnel – and doing essentially the reverse. His argument is based around how our efforts – and investments of money and time – should be focused more on retention than acquisition. Hmm. Ok, I’m listening. Go on.

He asserts that by taking this tact – investing more on retention than acquisition – we can effectively think of the sale – formerly the optimal end state – as the beginning to what will ideally be a long and meaningful relationship with said customer. I know that all sounds a bit fluffy and pie-in-the-sky, but he’s making some good points so far so I’m going to stick with him to see where it leads (plus, it’s a required reading for a paper I’ll be writing later in the course so I’m not sure I really have a choice anyway)!

Stay tuned for more updates on this book as well as my insights, thoughts and maybe even the odd limerick or haiku on the topic B2B marketing over the next couple of months.

 

1 Comment

Filed under Books, Business, Management, Marketing

Not All Requirements Created Equal

requirements pic

In the world of software/web/app development there is no shortage of talk about ‘requirements’. Depending on the methodology you subscribe to (or don’t), you’ll have a point of view on topics such as how detailed ‘requirements’ should be at the various stages of the project or product life cycle, as well as the level of rigour that should be applied to managing them.

There are also many different approaches to eliciting requirements (i.e. workshops, interviews etc.) and similarly, there are many different ways of documenting requirements (i.e. use cases, process models etc.). Making these types of decisions will be based on things like the type of project, technology and customer you’re working with as well as your personal and team preferences based on what has worked (or hasn’t) in the past.

Prior to making these types of decisions for any given engagement, it’s often helpful to take a minute to define what exactly a requirement is, because like many things in life, it can mean different things to different people. Based on the International Institute of Business Analysis’ (IIBA) ‘A Guide to the Business Analyst Body of Knowledge (BABOK)’, version 2.0, a requirement is defined as follows:

  1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
  2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
  3. A documented representation of a condition or capability as in (1) or (2).

These definitions may be different from how you might be inclined to describe a requirement, but a good case can be made for taking the time to describe them. Another step that is helpful is to define and set expectations around the types of requirements that will be applicable on your project. The IIBA BABOK_v2.0 outlines the following classification scheme:

Business Requirements are higher-level statements of the goals, objectives, or needs of the enterprise. They describe the reasons why a project has been initiated, the objectives that the project will achieve, and the metrics that will be used to measure its success. Business requirements describe needs of the organization as a whole, and not groups or stakeholders within it. They are developed and defined through enterprise analysis.

Stakeholder Requirements are statements of the needs of a particular stakeholder or class of stakeholders. They describe the needs that a given stakeholder has and how that stakeholder will interact with a solution. Stakeholder requirements serve as a bridge between business requirements and the various classes of solution requirements. They are developed and defined through requirements analysis.

Solution Requirements describe the characteristics of a solution that meet business requirements and stakeholder requirements. They are developed and defined through requirements analysis. They are frequently divided into sub-categories, particularly when the requirements describe a software solution:

  • Functional Requirements describe the behavior and information that the solution will manage. They describe capabilities the system will be able to perform in terms of behaviors or operations—specific information technology application actions or responses.
  • Non-functional Requirements capture conditions that do not directly relate to the behavior or functionality of the solution, but rather describe environmental conditions under which the solution must remain effective or qualities that the systems must have. They are also known as quality or supplementary requirements. These can include requirements related to capacity, speed, security, availability and the information architecture and presentation of the user interface.

Transition Requirements describe capabilities that the solution must have in order to facilitate transition from the current state of the enterprise to a desired future state, but that will not be needed once that transition is complete. They are differentiated from other requirements types because they are always temporary in nature and because they cannot be developed until both an existing and new solution are defined. They typically cover data conversion from existing systems, skill gaps that must be addressed, and other related changes to reach the desired future state. They are developed and defined through solution assessment and validation. documentation and communication) tasks that can be performed in order to understand how a solution will deliver value to the sponsoring organization.

It’s important to note that – much like the ‘Project Management Body of Knowledge’ (PMBOK) in the Project Management world – the BABOK isn’t intended as prescriptive ‘how to’ for delivering projects but rather a framework for describing Business Analysis (including requirements elicitation, documentation and communication) tasks that can be performed in order to understand how a solution will deliver value to the sponsoring organization.

With this in mind, the exact definition and categories outlined in this post may not always work for all your projects. But be that as it may, the process of taking a bit of time at the outset of your projects – as a means to establish a common language with the teams and stakeholders – can help to get the project off on the right foot.

Source: A Guide to the Business Analyst Body of Knowledge (BABOK) – Version 2.0.
Image source: http://www.compulegal.eu/files/pm.htm

Leave a comment

Filed under Business Analysis

Performance Management Wrap Up

job performance

I just wrapped up my MBA course on Performance Management this week. Before I move onto the next course, I thought I would take a minute to summarize just some of the key points from the course, both for my own purposes as well as for the reading pleasure of anyone who is interested in taking a few minutes to see what has been keeping me from having the time to update my blog for the last number of weeks.

Consistent with the name of the course – Performance Management – the course was largely about; hey you guessed it – Performance Management systems. The word system is a pretty broad word that can mean many things to many people depending on the context. As such, a Performance Management ‘system’ is going to mean something to different to every organization. Understanding this, and that there is no universal, hard-fast approach for the successful design and implementation of a Performance System, here are just some of the major points that came out of this course for me that – I would think – would be applicable to most situations:

  1. A performance management system is much more than a series of performance appraisals
  2. Should align with organizational and departmental strategic objectives and priorities
  3. Should focus on the past, present and future (employee development)
  4. Can have impacts, both positive (i.e. motivation, empowerment, productivity) and negative (i.e. cynicism, turn-over, dissatisfaction) and as such should be carefully planned and executed
  5. Should be sized and designed in accordance with the size, structure and culture of the organization (one size does not fit all)
  6. Should properly account for individual as well as team contributions and performance in alignment with how teams are utilized in the organization
  7. Should be designed and implemented in such a way as to reduce the possibility of rater biases (halo effect, error central tendency, etc.)
  8. Training on performance management for everyone, especially the ‘raters’ is imperative for success
  9. Job roles as well as performance expectations should be clearly defined and communicated (as well as specific, measurable, achievable, realistic and time-bound; SMART).
  10. Should be focused on behaviours as well as outcomes
  11. Should provide clear links between effort, resulting performance and rewards (financial or non-financial)
  12. Should understand and account for different personality types (introverts vs. extraverts) as well as different forms of motivation (intrinsic vs. extrinsic)
  13. Employees should be involved in its creation, delivery and evolution
  14. Should be an ongoing/iterative/continuous process
  15. Communication at all stages is key

In addition to the points above specifically related to performance management ‘systems’, here are a few other related subjects that were touched on during the course – each one of which could be a course on its own (and a few of which I plan on posting further on later).

  • The Four Temperaments for Peak Performance (I anticipate a blog post on this one soon)
  • Team based learning (the approach that was used for this course)
  • Case study/story board method (also used for this course)
  • 360 Review Systems
  • Coaching process
  • Giving and receiving feedback
  • Managing vs. leading
  • Personality types
  • Reward systems
  • Motivation
  • Maslow’s hierarchy of needs
  • Myers Briggs Type Indicator

In summary – despite their absence on the actual balance sheet, most organizations will say that their employees are their most valued asset. Those that truly believe this will figure out how best to create a ‘Performance Management System’ that works for their organizations and employees to drive employee development & satisfaction which will in turn, will help to drive all of the important organizational metrics.

Leave a comment

Filed under Business, Management