Requirement Development – Iterative Model

What is Requirement Specification? What is Software Requirement? What is requirement Engineering?
Before we answer these questions on Requirement Management, and requirement Specifications, let’s talk about the following!
  1. A process is a description of how to accomplish a work activity
  2. A procedure is a set of steps for accomplishing the work tasks of a process
  3. A technique is the way an individual accomplishes a procedure

This is it that we have in Software development. How can you be a brilliant Software Developer! Ah, Amit, C’mon, you must have had lost your senses! We’re good developers / Testers, and Project managers!

Do you really think so, if you do, let me know how many items out of the mentioned below you follow while doing development!

  • Do you follow coding style guidelines
  • Do you follow code documentation guidelines
  • Do you really use debugging tools
  • Have you ever done your code being peer reviewed
  • Do you even know about testing strategies, procedures, and tools
  • Do you even know what periodic backups are
  • What isa version control system
  • Do you know how to use a defect tracking system
  • What isa design documentation tool
  • What is with requirements traceability tool
  • What do you know about project planning and tracking system

I bet most of you developing the code (and no offence here), would know at max about 2 or 3 of these. Reason, well primarily you don’t think that it is necessary OR it’s not your responsibility! Whatever is your reason, of you’re not following all the above you would surely be successful in your career BUT only in very short run!

Now here is a thing which we all should be aware of. Your project may follow the ‘Waterfall’ approach, BUT it is not necessary that during the requirement gathering phase too you have to follow the same model. You can always and in fact should always utilize various approaches for doing various activities of SDLC.

Here is how you should do Requirement Development using Iterative approach.

Requirement in an Iterative way!

Requirement in an Iterative way!

Now let’s talk about the Process flow for Requirement Development.

Why is it that my entire focus is on Requirement Analysis and not on other aspects of SDLC. Think about it! Majority of the time project failure is because of Improper Requirement Gathering—Yes, believe me, this is from experience!

Any available Software Projects workflow will have varied components, and requirement development is one of them.

Requirement Analysis Work Flow

Requirement Analysis Work Flow

Below mentioned is the COMPLETE detail on how Requirement should be done, following the requirement iteration flow!

Requirement Analysis - How

Requirement Analysis - How

Did I ever tell you what Requirement actually is?


Requirement is : The external (user) view of the system
                                                                              Which Includes
Functional requirements (what must the system do?)

                                                                              Which are

Prioritized as Essential, Desirable, Optional

and prioritized within categories, which also has

Quality attributes (how well must the system do it?)

                                                                              Which Includes
Safety, security, reliability, performance, throughput, capacities

Can also be prioritized
– e.g., security versus performance
• Usually apply to multiple (perhaps all) elements of the system
• Each operational requirement is tagged as “valid” or “design goal”

Simple isn’t it…Cheers! We will start with Project Planning Tomorrow!

Project Management Cycle – via pics!

Let’s learn Project Management easy way!

We have been talking a lot of stuff which was more ‘Textual’ in nature, and today let’s respect ‘A picture is more than thousand words’ – the phrase!

Now let’s see as to how each and every element is so very important for us. This way you’ll be able to align this with CMMi. And that is an essence to learning CMMi.

CMMi Supporting Process

CMMi - Supporting processes

By the way we have been discussing about processes! What exactly is Process?

There are three key factors in software engineering:

  1. People: numbers, skills, morale
  2. Process: This is a procedure for doing the work
  3. Technology: This is characterized by platform and domain

Good processes help people apply technology
Efficiently: without wasting time, effort, or
and Effectively: while obtaining the desired

What is a Process?

A process is a systematic way of doing things:

Systematic means any action which is teachable & repeatable

A model associated with a process specifies:

  • the work activities to be accomplished
  • interconnections among the work activities
  • the input work products on which work activities are based
  • the output work products produced by work activities
Waterfall Model

Waterfall Model


We will talk about these in detail, but today, please make sure to understand every aspect of each and every image attached here:

Engineering Processes

Engineering Processes


CMMi – Project Planning – Resourcing

Work Breakdown Structure and Schedule The figu...

Image via Wikipedia

Ironically, though resourcing the product team members is a very important and significant part of a project manager’s role, not much focus is placed on resourcing. Because of this, we’ve encountered many project managers that are overwhelmed, worn out, and in many ways, well ineffective. Who to blame for?

In my own projects, I have been so very little blessed with good resourcing, and I am not talking from the perspective of ‘Skills’, I’m talking about manpower! 30% here, 10% there, 10 % I don’t know where, and remaining 50 % of the same resource already is planned for some other projects! Seems familiar…wow! look at the smiling faces of few PMs around 🙂

So rather than giving ‘Gyan’, let me ask you a very simple question, and before that; Resourcing is not just ‘Man-power’, resourcing includes, but not limited to, manpower, equipment, methods etc. So my question would be:

How do you plan for the necessary facilities? How do you plan for the necessary staff?

The top-level WBS, remember we developed it under estimation mechanism is typically explained / expanded by decomposing the top levels into small workable items that that can be separately assigned, performed, and tracked.

Now as this may be seen as additional work, but believe me, always remember to ‘Break-it-down’, this is so very important in our estimation and resource allocation methods.

You can or in fact should assign WBS a unique identifier (e.g., number) to permit tracking. A WBS generally is based on requirements, activities, work products, or a combination of these items.

So to answer the question that I asked, You do it this way:

You can provide excerpt from Project Plan (Say Project Delivery Approach), the MS project plan, or any other means of WBS of the project plan that identifies the need, available tools, schedule and budget etc.

You should provide excerpt from Project Plan that identifies staffing need, available staff resource, and plan for recruiting etc.

Scope of Work - MS Excel Work Breakdown Struct...

Scope of Work - MS Excel Work Breakdown Structure template (Photo credit:

CMMi – Project Planning – Identify Risk

Risk: One of the most important component for any of the Project Planning related activities.

Does this scenario seem familiar : “Ah, you know what we planned that we will be able to create this webservice in a week’s time, and suddenly this the Dev is not available!” So? You planned for this…right, this is a risk? Yeah…Ummm…you know what, I didn’t…!!! What???

Well this must be familiar with many of us under various circumstances as we move ahead in our projects. Hence Identifying and analyzing the project risks is a massive opportunity for us as a project manager  to make sure that the deliverable are running on time. So, How do we do this?

Now this is where things gets slightly trickier as we move! The identification of risk involves following two aspects:

  • Monitoring the Risk (This is part of PMC – Project Monitoring and Control)
  • Risk Management (This is part of Risk Management – RSKM)
English: The diagram above represents a generi...

Image via Wikipedia

We will talk about these in near future, but for the sake of this discussion let’s talk about why Risk identification is necessary?

Risks are identified or discovered and analyzed to support project planning. Now this is an exercise which should take place across all plans that affect the project to ensure that there is an interface among all relevant stakeholders on identified risks.

Remember this : While doing project planning, the project plan is supported by various documents, and hence Identifying the Risk is a filler for Project Planning, which means that this filler itself has a procedure to be followed.

  1. We should identify the Risks.
  2. Analysis of the risk, and determination of the impact, probability of occurrence
  3. Giving priority to the risks

Let’s talk about how do we identify the risks:

Examples of risk identification and analysis tools may include the following:

  • Risk assessments
  • Checklists
  • Structured interviews
  • Brainstorming
  • Process, project, and performance models
  • Cost models
Here is the model associated with Risk Management:
CMMI Project Planning – Meta-data model

Image via Wikipedia

Once this is done, then we document the risk, and review and obtain the stakeholders approval and agreement.

Once you’re done with doing Risk identification, you should have answers to the following questions:

How are Risks identified and analyzed?

The answer for this should be:

Well, we have a list of identified risks, and we call this a risk watch list, a risk plan, which has got documented analysis of the risks, and very importantly we do have a Standard set of typical risks for specific type of  projects.

We will be talking about other aspects of Project Planning and probably by the end of this week you all should have better understanding of how to do Project Planning. Cheers!

Project Plan – How to Budget and Schedule!

Conflict engages. If people have no opinions, no objections and no emotions, it usually means they don’t care. And you’ll be hard-pressed getting their help when you have to actually implement your idea.

So, our Project Manager Rehan is having a very hard time in understanding the Project Plan, and he is a Project Manager, what an irony…well, this does happen with many of us, so lets go ahead and understand as to what all we need for “Estimating Budget and Schedule”

Any project has a defined and allocated budget and the associated schedule which are based on Estimates and it is the responsibility of the project manager to make sure that budget allocation, task complexity, and task dependencies are properly addressed. And how would Rehan do this, by Project Planning.

We are here looking for

  • Schedule of Project
  • Budget of Project
  • Schedule dependencies

You have to understand what are your major milestones. If any project includes a QA milestone, then the QA review is conducted to ensure that the assumptions and requirements associated with that milestone (Say the milestone was to complete writing of test cases) are being met or not!

You should definitely look out for assumptions made in the schedule.

Another very important aspect is to talk about Constraints, I mean the factors which limits your flexibility. Like resources, task duration, complexity, outputs!

Dependency on task is a massive contributor for projects getting delayed. We never anticipated that UI team will not be available, and we forget to include their time! Hell No!

For establishing and maintaining the project’s budget and schedule think on these lines:

  • You should define the availability of resources whether they are committed or expected
  • You should understand that work being done in phases give much better result, so provide timeline for activities
  • Break It! Essence of any task, you should provide the breakout of major schedules
  • I don’t like dependencies, leave this for any other day, while planning you got to define dependencies among activities!
  • How would you measure your project, the keyword is Milestones! Define them!
  • Identifying the milestones, and releases for the delivery of products to the customer
  • This is of massive importance, Provide appropriate time gap between defining milestones!
  • Documenting project assumptions and rationale

So this is all you need to think and understand before you decide on project budget and schedule! Next we will discuss about Risks!


CMMi – Project Plan – Introduction

Project Planning

Heard of this…hah! you got to be kidding me Amit, you seems to have lost your senses…this is what we do daily, we talk about this delay, we always say that our project is getting delayed…we are missing deadlines…we are not on track…. :), we do have a plan dude! I see many of you thinking aloud this in your mind…well good for you…now go back and read the same lines again…one more time…

we talk about this delay, we always say that our project is getting delayed…we are missing deadlines…we are not on track…

And you say you have a project plan, and you talk about this daily…now is my turn to say…YOU must be kidding me! How can you ever have a delay in your project, how can you ever miss a deadline…IF you ever had a Project Plan!!!! Have it in your face…I am loving this giving you back…

From today let’s make things a bit “Real”…let me introduce Rehan as a character in this journey, and Rehan…he will be a project manager in our organization…so what does Rehan do…, tell us Rehan!

Well Hi, I am a project manager, and I should be managing the project…OK, sounds good…why is that I am made a project manager….? Well, I did good in one project, I am out spoken…my boss feels I can be good in client communication, and well, I speak a bit of jargons!


Does that make you a good project manager…hold on…we are diverting, our job is to understand Project Planning and not to determine my worth of being a project manager…

All right…perfect, so lets start with asking few questions from Rehan!

What is a Project Plan…Mr. Rehan?

Ha!..this is a plan for the project, in which we have everything…

Can you be more specific?

Well…I mean…OK, if you feel you’re so good, tell me what is Project Plan?

With Pleasure Mr. Project Manager!

A project plan is a formal, approved document which is used to manage and control the execution of the project.

It is based on project requirements and established estimates.

The project plan should consider all phases of the project lifecycle.

Oh! Yes, now I know…hmmm… this is exactly what I meant…just that not coming out! You know…its been a while, I am more of a practical guy!

Ah…practical guy…right…ok…tell me about this…

Do you:

  1. Establish the Budget and Schedule?
  2. Identify the Projects?
  3. Plan for Data Management?
  4. Plan for resourcing?
  5. Plan for Knowledge transition / Training?
  6. Plan for a Project Plan?

So, Mr. Practical Project Manager?

See, this is what happens, when we think we do…but in reality we are far away from doing! And this is where we want all of us to understand and be on the same page!

In tomorrow’s post, will go through these topics in detail and we will also see, what are the work products associated with Project Planning!

Till then…Cheers!

CMMi – Project Planning – Estimation Continued!

Ok, so we were talking about the Project Planning, and under Project Planning we were over to the first part which is Estimation. So what actually estimates include?

We know about Guess(ti)mate, Error-n-Judge-n-implement, Experience, and Ball-park! But, to achieve at a new way to learn “how to Estimate”, and do it in a mature (Level-2) and defined (Level-3) way…let’s get started:

Whenever you start doing estimate, you’ve to understand about the work, which is supposed to be done by your resources. We call it, WBS(Work Breakdown Structure). This is primarily done to understand the scope of the project.

At the beginning of the project, this may term as a factor for initial Estimate. The objective of this WBS is to divide the overall project in to s,all interconnected set of manageable component.For eg., say you’ve to develop an eCommerce site, which will include:

  • – Evaluate the potential of current website
  • – Communicate on the said plan
  • – Decide upon its potential and prospective decisions, whether to restyle or replace (if required)
  • – Differentiate key areas to manage and organize the project
  • – Implement sales, tasks, employee, product, client and money management solutions
  • – Devise customized solutions to heighten the sales and achieve the coveted goals

Now a WBS will mean coming up with the timings on each of these actionable items. So you SHOULD “identify and organize” the logical units of the work which is to be managed.

Once a WBS is defined you’ll then have a reference which will be used for assigning Efforts, Schedule, Responsibility for coming up with a plan.

Now while defining WBS you should consider the following:

  • Risk and how you’re going to mitigate them
  • Task for deliverables
  • Tasks for Skill, Knowledge, and Training sessions
  • Tasks for Development plan, QA plan, and Configuration management plan

The more detailed the WBS is the more realistic this will turn out to be. An example would be (Courtesy wikipedia):

Work Breakdown Structure


Now once we have identified the scope of the project at a high level, now is the turn to establish the estimates of the work products:

In many of the associated models which are used to estimate effort, cost, and schedule of the work, SIZE is the major input. You can also include SLAs (Service Level Agreements), Connectivity, and Availability etc.

Lets see a bit of examples:

  • Number and complexity of requirements
  • Number of functions that you’re going to use
  • Function points – what all are function points
  • Source lines of code – especially in OpenSource
  • Experience of project participants
  • Number of classes and objects – This is something architecture needs to define
  • Number of database tables – The database and the structure needs to be defined and understood
  • Number of fields in data tables
  • Architecture elements
  • Amount of code to be reused versus created
  • Number of inputs and outputs
  • Number of technical risk items
  • Proximity of customers, end users, and suppliers
  • How agreeable or difficult the customer is
  • Quality and “cleanliness” of the existing code base

One important point to consider is that while determining the estimates, your estimate should be in sync with project requirements.

You should definitely talk about the technical approach which defines a strategy for development of the product. It includes decisions on architectural features, such as distributed or client/server; Cloud based computing etc.

The last thing that you would need for is to learn about “How to learn about Estimating Efforts and cost”

This is an essential component for Project Planning.

The objective is to Estimate the effort you are going to put in project and cost for work products. This is primarily based on estimation rationale.
  • You should collect all the historical data to convert the attributes of work products in to estimate of resource hours and cost.
  • You can also use estimation techniques like: Examples of effort and cost inputs used for estimating typically include the following:
    • Estimates provided by an expert or group of experts (e.g., Delphi method)
    • Critical competencies and roles needed to perform the work
    • WBS
    • Skill levels of managers and staff
    • Knowledge, skill, and training needs
    • Product and product component requirements
    • Size estimates of work products, tasks, and anticipated changes
    • Capability of tools provided in engineering environment
    • Technical approach

With this we come to an end of understanding of Estimates, and the techniques required for estimation, now another step would be to understand about the how to develop the Project Plan. Till then Cheers!

CMMi – Tailoring the processes!

Most of us have this question that why is it that one process or procedure can’t be implemented in all the projects with similar flavor! Why is that you’ll talk new, tailored processes for every project?

CMMI, is smart enough to recognize that one size does NOT fit all. Organizations which are tempted into the “one true process” quickly realize that actually “one size fits no one”. Even if the you create “one true process” by carefully looking at projects in progress at the time, no two projects can ever be the same and hence no Single process really fit new projects as they come along.

In fact CMMi is smart enough to make sure and embodies ideas to stop organizations falling into the “one true process” trap.

This is how we have been doing this at Tekriti. We first as part one of this entire exercise are trying to build a “set of standard processes” – enough processes to support the different types of projects that the organization has to deliver. We can think of these types of projects as forming families – for each distinct family there is a distinct standard process.

Then since CMMi allows us, we will go further and tailor the selected processes to better fit the needs of each specific project. Tailoring can only occur within permitted guidelines – to ensure that the performance of different projects remains comparable.  In particular, the quality of the work products produced will be comparable across projects.

CMMi is so very beautiful in terms of giving us further allowance for very unusual projects.  Recognizing that every organizations evolve continuously and will have to tackle new and unique challenges, projects are permitted to seek exceptions to the standard processes and tailoring guidelines. But there is a condition, your  project has to have a reasonable case for its exceptional behavior and describes how it will perform its work to ensure that the organization’s policies will not be violated.

If your organization is attempting “one true process” well, then from CMMi side you’re not fulfilling its requirements – they cannot achieve maturity level 3.

The “one true process” becomes a straight jacket that is almost impossible to change.

Now you may ask question that isn’t it easier to change one process than to keep several processes current? For to be kept up to date, that’s certainly true. But consider the problems from the other side. Different projects have different needs and it is though always good to have one process which fits all, BUT the problem comes when these projects requires contradictory changes – one project needs more agility, the other more formality…

Now, which changes are we going to incorporate into the process? If we incorporate more formality, the agile project is disadvantaged.  If we go for more agility, the formal project is disadvantaged.

And then, very quickly the strains on the process and the demands to change the process become so great, the “one true process” becomes an unsustainable position. Then comes the problem, which you never have solution for!

So One size NEVER fits all! And this is something you’ll will learn as and when we will come and talk to you all, and make you understand about the processes…and make you realize that your project needs are different from someone else’s, and hence a different process!

CMMi – A crash course – Introduction to Dev 1.3

Capability and Maturity

CMMI is an acronym for “Capability Maturity Model Integrated.” The last word basically means that CMMI is a fusion of best practices from a number of different capability maturity models that were eventually combined into a single model that is reminicent of the CMM.

Maturity means that whatever the company is doing, the company does it in a way that is well-documented, where everyone knows what is expected of them and perform accordingly, where performance is not dependent on heroes, and where decisions are made on proper analysis of the situation.

So there are three types of CMMi : Development, Acquisition, and Services. We at Tekriti are going for CMMi Dev Level 1.3

What holds everything together? It is the processes used in your organization. Processes allow you to align the way you do business. They allow you to address scalability and provide a way to incorporate knowledge
of how to do things better.

We all have our problems associated in day-to-day activities, CMMi provides you a way to solve these issues by providing streamlined methods. We will discuss and learn about all this in a matter of time and with every session as we move ahead!

Let’s start talking by Maturity!

Levels of Maturity

Search for CMMI on the web, and you’ll find the five levels of CMMI:

  1. Performed. This is where everyone starts: Our company is making products and you’re earning money, so evidently you’re doing something right. But you’d have a hard time describing precisely how you’re doing it. Your project teams may be managing by the book, but they certainly can’t tell you which book. You’re performing, but you don’t really know why or how well. I mean if I ask you now, do you follow the processes, well you’ll say Aaannn….you know …no! Well I don’t buy your argument then…you’re following processes that is why you ‘re here speaking with us and doing what you are “Supposed” to do :).
  2. Managed. At this level, your company’s project teams are well-functioning according to ordered methods that are well-documented. There’s no guarantee that one project team is managed by the same methods as another team, however, and each time a new project is started, you may find the team reinventing the wheel.
  3. Defined. This is where all of the methods are well-defined across your company, and all of the projects perform according to those methods rather than figuring them out on their own. And this is what we are targeting at Tekriti!
  4. Quantitatively Managed. The projects perform according to the same methods as at the “defined” level, but at the quantitatively managed level the projects will have plenty of hard data to back their decisions and performance. This enables the projects to make sound decisions and quickly identify deviations, and it obviously requires that the defined processes have been followed for a while.
  5. Optimizing. At the last level, the organization continuously focuses on optimizing its work processes. This requires plenty of statistics from the quantitatively managed level.

Since all companies start at level 1, the CMMI model doesn’t state any requirements below level 2. Level 2 is concerned with project planning and processes for managing projects, requirements, and suppliers, and introduces “support” processes that are vital for further maturity: configuration management, metrics and analysis, and quality assurance.

Level 3 introduces a large number of processes. Risk management is added to the project management toolbox, and the project management processes are expanded with processes for integrating separated teams in the management. This level also introduces three processes aimed at defining processes at company level rather than project level. Level 3 also involves processes for constructing products according to well-developed requirements, and for verifying and validating the products.

Level 4 adds processes for assessing objectively how the various processes perform, and for managing according to objective metrics and statistics.

Finally, level 5 provides processes for maintaining an organizational environment for innovation and for identifying and correcting the cause of problems and inefficiencies in the processes.

Well…this is it for today….will catch you soon with other sessions…Happy “Processing” 🙂 Cheers!

How to handle clients with varied sense of UX

An excellent article, which explains in detail about how to handle various clients depending non their  ‘Usability and or UX’ understanding.

Project management, and UX strategy to me, these fields are inextricably linked as part of the planning phase of any project.

In this article let’s learn about how to introduce two things:

  1. A governance framework that walks through the value of UX during various stages of a project.
  2. Hurdles UX strategists face, and how to overcome them.

Experience Design Process

The following presentation outlines the various documents that can be created during the planning phase of any project. Although it’s rare that all of these documents would be required, a number of them will be useful for every project. It’s a good template to reference on every project to ensure you’re setting the project up for success.

The Experience Design Framework

With the planning phase defined, the role of a UX specialist often gets forgotten. Throughout the project lifecycle, a UX specialist can be invaluable to the success of a project. In this document, I describe how to integrate the role of a UX specialist into every phase of a project, regardless of the project management methodology used.

The UX Project Lifecycle

Clip from The UX Project Lifecycle
(Download PDF – 61kb)

External UX Hurdles

Risk-averse client

Hurdle: Risk-Adverse Client

Issue: A Risk-Adverse Client is a common issue that pops up on many projects. The client will push back on any innovative solutions, and will not want to commit to a single solution without testing, written rationale, or other 3rd party support.

Overcoming: The easiest way to overcome this is through upfront stakeholder interviews. If you detect a Risk-Adverse Client, you will need to probe for the root cause of their fear, and may need to perform upfront research or user testing to help assuage the client’s fear. Doing this upfront will do two things: 1) it’ll show you’re taking the client’s concerns seriously 2) it’ll prevent fears from inhibiting innovation further down the project pipeline.

New World Client

Hurdle: New World Client

Issue: It’s said that in 1492 when Columbus came to America, the native inhabitants were able to look out over the ocean, full of ships, and see nothing but water. They had never seen ships before; in fact, they’d couldn’t even dream of such things. The only way they knew a contingent was on approach was because of the ripples the ships caused in the ocean.

This is the same issue that New World Clients have. It’s known as perceptual blindness, and it’s contested whether or not it actually exists. In this case, New World Clients might push back or make unusual requests because they’re used to having things look, feel, and behave in a certain way and don’t know any other way to think.

Overcoming: Just like the first person to spot the ripples in the water, you need to get the New World Client to see that something new and important is on its way. Show them examples, prototypes, or any other materials that illustrate that what you’re proposing is right. New World Clients need special attention, but much of the attention should be given during the onboarding process.

Big-Eyed Client

Hurdle: Big-Eyed Client

Issue: Think kid in a candy store. The Big-Eyed Client wants everything, every feature you could name. A great indicator that you might have a Big-Eyed Client is vendor-itis; if your client has more than five vendors providing niche services on a single site, there’s a good chance you have a Big-Eyed Client. These clients will push for as many features as possible, regardless of the impact on user experience.

Overcoming: Again, an ounce of prevention is better than a pound of cure. In this case, prioritization and focus are key to reining in a Big-Eyed Client. This can be done in a number of ways: by prioritizing user flows, scenarios, user stories, or a feature list. Adaptive Path recounts this process in detail here starting on slide 52

Fox-in-the-Hen-House Client

Hurdle: Fox-in-the-Hen-House Client

Issue: This is an example of the Highest Paid Persons Opinion (HIPPO) effect, where a misinformed UX advocate holds an elevated position within an organization and can influence everyone else simply by offering his opinion. In many cases this type of client will offer outdated or misinterpreted information he’s read or heard from others. No client wants to create problems for the user; the Fox-in-the-Hen-House client believes what he’s saying is true, and will benefit the user.

Overcoming: Don’t argue a specific issue—you’ll never win. Even if you end up winning the issue at hand, you’ll have built animosity between yourself and the client. Instead, focus on imbuing the wisdom that a single solution isn’t right all the time, and that different contexts require adapting and manipulating solutions to improve an experience. Even banner ads worked until we realized users were developing banner blindness.

Can That Be Done Client

Hurdle: “Can That Be Done?” Client

Issue: In many (if not most) organizations, the client contact you’ll be interacting with will not be familiar with technological constraints. Additionally, he may not be familiar with emerging conventions and new types of tools and technology that are available. The issue this type of client will often create is one of hesitation; he’ll want to pass every innovative idea past their IT department. As we all know, IT departments can be the place where innovative ideas die.

Overcoming: Being able to navigate the pitfalls of an IT department is a skill few people possess. However, if you have access to a seasoned developer (or better, can develop a relationship with one of the developers within the IT department), you can utilize that person to communicate how a solution could be implemented.

Too Many Chefs Client

Hurdle: Too Many Chefs Client

Issue: When working with clients that are part of larger organizations, there may be a lot of stakeholders, all looking out for their own interests. In many cases, these varying interests conflict with one another, and prioritization of these interests becomes unmanageable.

Overcoming: Rather than trying to accommodate everyone, it’s best to take a two-step approach to preventing this issue:

  1. Produce a comprehensive content inventory either by auditing the existing site/app, or by developing a new one. This will help identify all the potential stakeholders. Tip: Add a responsibility column to your content inventory and get the client to fill it in. This should outline the business owner of each piece of content that will be created.
  2. Facilitate a prioritization breakout session with representation from all stakeholders to determine whose content will be considered mandatory on all shared content pages and modules.

Astronaut Client

Hurdle: Astronaut Client

Issue: The Astronaut Client is a visionary; he doesn’t want to get bogged down in details and knows what he wants when he sees it. This type of client, while open to innovation, is often only open to innovative ideas that mesh with his perception of his vision. A big issue I’ve run into with Astronaut Clients is that they often don’t want to review planning documents, but will reserve feedback for visual design.

Overcoming: A standard onboarding procedure should address this issue. The client should either be educated on the process they’ll be asked to run through, or asked to provide a proxy who can review and provide approval to elements the Astronaut Client doesn’t want to review.

Proxy Client

Hurdle: Proxy Client

Issue: A proxy client is generally a person who’s selected to represent the interest of another stakeholder because that stakeholder is too busy or unavailable to interface with you directly. This is an example of “broken telephone,” where an opportunity exists for the proxy client to misinterpret direction from the stakeholder due to a lack of background information.

Overcoming: Strong relationship management skills are required to overcome this issue. The easiest way to work with a Proxy Client is to ensure regular reviews are scheduled with all vested interests. When that is impossible, a governance document may need to be created to have some documentation on what elements the Proxy Client can approve, and what elements the Proxy will take back to the stakeholder for approval. Tip: Never allow the Proxy Client to present your work to the stakeholder. Whenever possible, present your own work.


If you use the Experience Design Framework, and follow the process laid out in the UX project lifecycle, you’ll experience far fewer hurdles. If you’re not able to do this for whatever reason, you’re likely to face some of these hurdles.

You’re now equipped with the tools you’ll need to combat the hurdles you may face from these types of clients. That said, you may face combination clients who have traits from several of the above types. If this is the case, you need to consider both your well being and your organization’s well being.

Ask yourself, “Is this work going to be worth the education and relationship management required to transform this client?” I’ve phrased this question deliberately, because I’m assuming you wouldn’t want to simply capitulate to every client whim, and you wouldn’t want to invest in a client that isn’t willing to produce quality work.

If it is worth the time and effort required, you may need to schedule an education session. Earlier this year I was hired as a consultant for a major Canadian financial institution where I was able to conduct such a workshop. It uncovered major organizational issues that couldn’t be corrected immediately, but caused stakeholders to be cognizant of their potential biases. These issues were also documented and raised to the corporate HR lead and the executive team. I was also invited to give a high-level presentation to the board of directors, who will be considering several proposals my team made.

This is all to say, if you’re a digital shop who’s working with a client, you have options to make your relationship much more valuable and fun. If you’re a marketer, consider hiring an agency that is capable of offering you the direction you need. If you’re hearing “yes” to all your ideas, or are being required to provide more direction that you believe should be required, you probably have an agency that doesn’t understand the nuances of UX strategy. If this is the case, consider hiring your own consultant to provide the project with guidance, or consider finding an alternate agency that can.