Do Users Know What They Want?

Steve Jobs Quotes from MacStories in what I think of as his thoughts on users/customers:

“You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new.” –  Inc. Magazine

“It’s not about pop culture, and it’s not about fooling people, and it’s not about convincing people that they want something they don’t. We figure out what we want. And I think we’re pretty good at having the right discipline to think through whether a lot of other people are going to want it, too. That’s what we get paid to do.” – CNNMoney

“So when a good idea comes, you know, part of my job is to move it around, just see what different people think, get people talking about it, argue with people about it, get ideas moving among that group of 100 people, get different people together to explore different aspects of it quietly, and, you know – just explore things.” – CNNMoney

That first quote has really stayed with me ever since I first heard it during the Steve Jobs media flurry that occurred just after his death.  I think this is because it applies so aptly to what I do as a Business Analyst on projects.  It is my job to determine how to deliver what customers really want, to understand how they need to use the system.  Of course, working with management up front before selecting the tool would be optimal but most of the time the tools have been selected beforehand and that is a constraint.

That reality aside, this process sounds easy right?  You just ask them.

Well, most of the time it doesn’t work that way at all.  Why?  Well, because most users only understand some aspects of their job and although they understand the steps they go through to get what they need every day, they can’t really visualize what the best way to do their job is.  They can’t really see the possibilities and they freeze up in the face of change.  Oh they may seem confident, but if you’ve ever sat down and gone through the process of documenting what they say they want just to have them see the reality and figure out that they didn’t want that at all, you understand that they really don’t know.

Projects want to deliver value to customers, or in the IT world what I think of as users.  Projects management is all about defining objectives, scope and requirements.  The unspoken assumption behind all of these tasks is that the users (or customers) know what they do, why they do it and what they want.

In my experience high level managers want effective investments with positive ROI through cutting costs and increasing efficiency.  They also need to keep up with competitors, and this often means investment in keeping up to date with their product offerings and technology.

What do most users want?  Well they want to be left alone to do their jobs, and to do them the way they always have.  Sure they may complain about small aggravations, and they’d love to have them go away, but most users do not want the stress and effort that comes with redefining the way that they do their jobs.  They don’t want BIG change.

So what is to be done then, if we cannot rely on users to tell us what they want?  I think that it is important to ask them, what is it you need to do your job?  At the end of the day what value do you produce for the business and how does that tie in to what others do?  Then we need to say okay, I understanding the tools available, how would I want to produce what is needed?  If I was the one doing that job how can I make it easy.  Of all the possibilities, which way makes the most sense?

Once you have this worked out you can engage the people involved and explore all the different aspects of it.  Criticizing a new method is much easier than developing it.  What you will find is that presenting a fully fleshed out process allows users to draw on the knowledge they have to figure out flaws in your design so that you can work out the details.

So what do you think?  Have you found ways to deliver what customers really want?  Have you also found that often they don’t know what that is until they see it?


The Systematization of Campo and Six other Principles for a Successful Business

In one of my classes this week we had Mark Estee come in to speak.  Mark is the Owner of the restaurant Campo here in Reno.  His purpose was to talk about how he has leveraged social media to help his business however he also brought up some of what he has learned about running a profitable business that I wanted to mention here.  He definitely made an impression as a charming, funny, and savvy entrepreneur who is passionate about his business.

Although I was looking forward to hearing Mark speak, I didn’t think he’d have anything to say that would be applicable to my blog.  I was surprised to find that he had much more to talk about than blogging and tweeting.  What Mark really emphasized was the importance of systematization.

Mark spoke about Moody’s, his first restaurant, and how even though it was a popular restaurant with a lot of clientele, it was never profitable.  From the sound of it, he didn’t have systems in place that lent efficiency to operations and costs stayed high.

When he opened Campo he realized that he needed to systematize the processes of the business in order to create a business that was not only popular, but also profitable.  To achieve this systematization, he put efficient systems right into the design of the business from day one.

A few other principles he follows:

1) Have weekly meetings with managers and employees to constantly give them feedback both of the many things that go right, and to discuss what may have gone wrong.

2) He hires experts to manage aspects of his business that are not core to it such as marketing and accounting, but he does stay involved.

3) He knows each job in his business.  He’s worked in each position so he knows how it should be done and the challenges each employee faces.  When possible he still jumps in to help out where he can, whether that is in prepping the food, busing a table, or washing dishes.

4) He is always listening and staying involved, keeping tabs on what is being said about his business.

5) He engages with those who talk about his business online.  One thing he says about social media is that it can really help you or hurt you and you will be held accountable for whatever you put out there.

6) A good team is essential.  He wants employees who love to come to work each day, who believe in the business, and he structures his compensation so that they “have some skin in the game”.  It is important that your team cares that your business succeeds.

I can’t help but see some parallels between the business practices of a successful entrepreneur and a successful project manager.   The focus on systems and processes, teams and communication lends some credence to my idea that entrepreneurs are in many ways project managers.

I’ve not been to Campo yet, but I keep hearing good things so I will definitely make a point of going soon.

Are you an entrepreneur?  Please tell me about what systems you have in place that make your business successful, or those that you want to put in place.

Should Project Professionals Have Blogs?

I am now just passing the 20 post mark on my blog.  I’m also finishing up Spring semester at UNR.  It is a good feeling to see the light at the end of the tunnel.  This milestone, along with the lovely weather we’ve been having this week (it is in the 80s here in Reno) makes it feel like Summer is already here.  With that, I think it is a good time to ask  myself whether or not a blog is a good idea.  To keep going through Summer I will certainly need to believe that it is.

To answer my question, I found another video blog from The Project Shrink.  He certainly has my attention this week. In the video the main question is, whether or not a blog is valuable for a project manager. Bas De Baar interviews Stephane Grenier, author of “Blog Blazers“.  Frankly I’ve never heard of the book before, but then again it was released a couple of years ago and there is certainly no dirth of social media and blogging books out there.  It appears to be well rated on Amazon, so maybe I’ll check it out.

I found the most value in the first couple of minutes of the video during which Stephane gives two main reasons why writing a blog is a good idea:

1) a blog allows you to create a presence online that can help win you contracts for consulting work.

2) a blog gives you credibility and authority, especially in the field of IT.

So what do you think?  Does a blog harm you or help you?  I can certainly see the benefit of having a blog about your work if you are consulting, but what about the rest of us?

Elizabeth Harrin on Project Management and Women

In my search for project management wisdom I came across an interview with Elizabeth Harrin whose blog I read regularly.  It is always interesting to see a person speak when you have only previously read their posts.  She is the author of the blog ‘A Girls Guide to Project Management’.  She is also the author of the book ‘Project Management in the Real World’, which she also discusses in the video.  That book was written to help new project manager,who may not have a mentor, to act as a stand in for that missing mentor relationship.

This book was released back in 2007.  She now has a new book out, ‘Social Media for Project Managers’ that sounds interesting.

Some of the highlights of the interview are:

1)  She started her blog as ‘Project Management for Girls’ because alhtough she knew that there were females in the profession they did not seem to have a voice.  There just weren’t that many women project managers speaking about it, attending conferences, or writing about it.

2) Generally she does not see much difference between men and women project managers, with one notable exception.  She thinks that women are more likely to be effective at multitasking.

3) The challenges that she has faced in the workplace have not been related to her being female.  She does think that you never quite become comfortable with what you do, and if you have you need to stretch yourself.

4) If there is any theme to the advice she gives on her blog it would be around improving professionalism in project management.

5) Her advice to women who are new to project management is to get a small project, run with it and learn from your mistakes.

6) Finally, two errors that new project managers make are to either come in without confidence because they don’t feel they have enough subject matter knowledge or to come in with arrogance and then alienate the team and the stakeholders.

So, a good interview of Elizabeth with Bas De Baar, author of The Project Shrink.

Stages of Group Develpment

Not always, but often, I find myself a part of a new group.  This usually occurs with each new project I’m involved in.    I might find myself with some of the same people I’ve worked with in the past, but there is always at least one new member to change the group dynamic.

Given this I found it interesting to be reminded of Tuckman’s fairly well known theory of the stages of group development.  It is especially helpful to be reminded during the ‘storming’ stage, that the conflict that naturally develops is normal and temporary.    So here is a recap of the basics of each step of the theory, as found in the article 5 Stages of Group Development from

Image from The Happy Manager

“Stage 1: Forming
In the Forming stage, personal relations are characterized by dependence. Group members rely on safe, patterned behavior and look to the group leader for guidance and direction. Group members have a desire for acceptance by the group and a need to be know that the group is safe. They set about gathering impressions and data about the similarities and differences among them and forming preferences for future subgrouping. Rules of behavior seem to be to keep things simple and to avoid controversy. Serious topics and feelings are avoided.
The major task functions also concern orientation. Members attempt to become oriented to the tasks as well as to one another. Discussion centers around defining the scope of the task, how to approach it, and similar concerns. To grow from this stage to the next, each member must relinquish the comfort of non-threatening topics and risk the possibility of conflict.
Stage 2: Storming
The next stage, called Storming, is characterized by competition and conflict in the personal-relations dimension an organization in the task-functions dimension. As the group members attempt to organize for the task, conflict inevitably results in their personal relations. Individuals have to bend and mold their feelings, ideas, attitudes, and beliefs to suit the group organization. Because of “fear of exposure” or “fear of failure,” there will be an increased desire for structural clarification and commitment. Although conflicts may or may not surface as group issues, they do exist. Questions will arise about who is going to be responsible for what, what the rules are, what the reward system is, and what criteria for evaluation are. These reflect conflicts over leadership, structure, power, and authority. There may be wide swings in members’ behavior based on emerging issues of competition and hostilities. Because of the discomfort generated during this stage, some members may remain completely silent while others attempt to dominate.
In order to progress to the next stage, group members must move from a “testing and proving” mentality to a problem-solving mentality. The most important trait in helping groups to move on to the next stage seems to be the ability to listen.
Stage 3: Norming
In the Norming stage, interpersonal relations are characterized by cohesion. Group members are engaged in active acknowledgment of all members’ contributions, community building and maintenance, and solving of group issues. Members are willing to change theirpreconceived ideas or opinions on the basis of facts presented by other members, and they actively ask questions of one another. Leadership is shared, and cliques dissolve. When members begin to 1
know-and identify with-one another, the level of trust in their personal relations contributes to the development of group cohesion. It is during this stage of development (assuming the group gets this far) that people begin to experience a sense of group belonging and a feeling of relief as a result of resolving interpersonal conflicts.
The major task function of stage three is the data flow between group members: They share feelings and ideas, solicit and give feedback to one another, and explore actions related to the task. Creativity is high. If this stage of data flow and cohesion is attained by the group members, their interactions are characterized by openness and sharing of information on both a personal and task level. They feel good about being part of an effective group.
The major drawback of the norming stage is that members may begin to fear the inevitable future breakup of the group; they may resist change of any sort.
Stage 4: Performing
The Performing stage is not reached by all groups. If group members are able to evolve to stage four, their capacity, range, and depth of personal relations expand to true interdependence. In this stage, people can work independently, in subgroups, or as a total unit with equal facility. Their roles and authorities dynamically adjust to the changing needs of the group and individuals. Stage four is marked by interdependence in personal relations and problem solving in the realm of task functions. By now, the group should be most productive. Individual members have become self-assuring, and the need for group approval is past. Members are both highly task oriented and highly people oriented. There is unity: group identity is complete, group morale is high, and group loyalty is intense. The task function becomes genuine problem solving, leading toward optimal solutions and optimum group development. There is support for experimentation in solving problems and an emphasis on achievement. The overall goal is productivity through problem solving and work.
Stage 5: Adjourning
The final stage, Adjourning, involves the termination of task behaviors and disengagement from relationships. A planned conclusion usually includes recognition for participation and achievement and an opportunity for members to say personal goodbyes. Concluding a group can create some apprehension – in effect, a minor crisis. The termination of the group is a regressive movement from giving up control to giving up inclusion in the group. The most effective interventions in this stage are those that facilitate task termination and the disengagement process.
Adapted from: Tuckman, B. (1965) Developmental Sequence in Small Groups. Psychological Bulletin, 63, 384-399. Tuckman, B. & Jensen, M. (1977) Stages of Small Group Development. Group and Organizational Studies, 2, 419-427.”

Project Planning and Innovation

The May/June 2012 issue of Scientific American Mind is out and I just had to comb through it looking for articles that I might apply to Project Management.  There always seems to be something I can use, which says a lot about the applicability of Neuroscience and Psychology to the world of teams and management.  This little gem is titled “Focused to a Fault:  Planning ahead might make us overlook new solutions”.  This really says it all, doesn’t it?  Planning is great, right?  Planning prepares a map through the dark woods of a complex project fraught with hidden dangers.  It is tempting then to map out every little detail even if we have to make a lot of assumptions about the future to do so.  As with all good things however, there can be too much.  Not only can too much up front planning bog down a project and prevent it from ever getting started it can also cause us to miss alternatives.  Opportunities can just pass us by unnoticed because we are buried in the plan.

To give you more details, the article discusses a study published in the February issue of Social Cognition.  A psychologist at Wake Forest University by the name of E.J. Masicampo  conducted a study regarding the psychology of intentions.  In the experiment volunteers were given instructions to perform a task and some of these were also given an implementation intention in the if-then form.  Volunteers given an implementation intention were more likely to remember to do the task given to them but they were also less likely to see an easier alternative to complete their task than those who were not given the implementation intention.

“Masicampo…thinks being blind to alternative solutions “frequently results in people expending more time, energy and resources on tasks than is necessary”.  But that should not stop people from making plans, he says.  That may be the only way to juggle multiple goals — as long as one remembers to keep an open mind.”

So in what way do I think this might apply to project planning?  I think that a project plan is necessary and important but that care should be taken to make sure it does not become the bible.  Reality should not be forced to bend around the plan, rather the plan should be adapted to reality by a reiterative process of periodically moving back into the planning phase.  I also think that the project plan should never become so entrenched that the project team does not have the flexibility to take advantage of the opportunities in those dark woods rather than just reacting to the risks of them.

The Agile Project and The Business Analyst

My role on the projects that I work on is that of a Business Analyst, although my official title is Business Systems Analyst.  Recently I read another blog post that discussed the pros and cons of a Business Analyst on an Agile project.  Given that the article touched on a topic close to my own work I sent it out on Twitter.  The author came back to me asking what my thoughts on the topic were and I realized that they could not be encompassed in a tweet so I will address them here.

An image circluating the web, and also included in the post, is entertaining so I’ll include it here.  It mostly illustrates how difficult the actual process is.

My first reaction is that I have no idea if a Business Analyst is needed on an Agile project, as I’ve never worked on one.  Until very recently I’ve been one of many analysts that supports PeopleSoft ERP, a large software solution that is broken up into interrelated modules.  Outside of the large traditionally managed upgrades to the software,  I have been involved mostly on what I consider to be mini-projects where the users, myself and a technical resource (think programmer) are the only ones involved.  In this case a Business Analyst is a role that effectively overlaps other roles.  We do the tasks of a project manager (although at a micro scale), we are the SMEs (subject matter experts), we generally have some general technical knowledge and regularly act as the first person to research and trouble shoot issues or determine solutions.  We then wrap it all up for the programmers and test it once it is done to make sure the deliverable meets the requirements before turning it over to the users to test.  Finally, we document the final solution from the user/business point of view and train the user group acting on how to use the solution and act as a go to person once the solution is in to get the users functioning and to solve any problems that inevitably come up after the solution is in production.

From my forays into the Business Analyst community online I’ve gotten the impression that the Business Analyst role is a relatively new, and an increasingly important one.  Different companies and different teams use the role differently.  Some are required to be able to program where as at my work place they are not.  Given this there is a lot of debate in the IT world of what titles that contain the words “Business” and “Analyst” in them, such as Business Analyst and Business Systems Analyst title, really mean.  Even between the IT groups at my company Business Analysts perform different duties.

During the last major upgrade to our ERP solution at my company a very good technical consultant on the project let me know that at most companies the analyst (sometimes known as the functional analyst) is a much more respected and valued role than a technical one, which can be easily outsourced.  That in and of itself may explain the sudden upsurge in Business Analyst roles.  As technical jobs go overseas there is still the need to have someone at home who knows the business and can communicate with these resources in order to get a usable final product from them.

In any case, I see the role I play on the project as a vital one.  I say this because my role is often the one truly driving the changes and making sure that the software solutions in place meet the needs of the employees that use them.

Here are a number of areas that we add value:

  • We analyze user requests weeding out the work that does not actually require IT.  Sometimes it is a business process that needs to be changed, additional setup that needs to be done,  or a lack of understanding of the functionality of the software features in place.  A little time spent between a user and functional resource can prevent programmers from putting in time on unneeded fixes or customization.  A good Business Analyst can go a long way in helping to define and control scope.
  • We do a lot of work such as requirements analysis and initial testing that the user does not have the time or skill to do.  The users that are often called on to help to define requirements or test changes are also the ones that are the most experienced and utilized in their areas.  They are typically very busy.  It is not helpful to the company to have them off working with IT perpetually rather than performing their functions.
  • Most technical resources forget that users have no idea what they are talking about and often make the users feel lost and overwhelmed.  A good business analyst will be able to walk a user through the requirements and the testing process in such a way that the user is able to contribute their knowledge and expertise.  They can then turn and around and frame user feedback in such a way that it is useful to the programmer.
  • Most users have no idea what they want, they only know that they need a solution.  The might say “make this better” or “recreate this thing we already have”, but requirements of this type are very frustrating place to develop software from.  A good Business Analyst gets to the heart of what it is the user really needs.  What is the end result they are looking for?  How will they use it?  From here the requirements can be created and given to the technical in a form that gives them something solid to work from.  Programmers should not have to guess at what is needed.

If the argument is “why can’t other members of the project team pick up this responsibility?”  The answer is they may be able to, but there is a tendency to underestimate the difficulty involved in doing this role well.  Technical will meet with users and try and define requirements but may not understand what the user is asking for any more than the user will understand the technical point of view.   Programmers that I work with need to have uninterrupted time to deliver.  Will they be able to do this if a user is coming by, e-mailing or calling constantly with some new emergency or concern?

I found another post that probably does a better job of describing what a Business Analyst actually is.  Definitely take a look at it if you want another point of view.

I also recently discovered a new official body of knowledge and certification has been formed around the role, in a similar fashion to the PMP certification for the Project Management role.  The IIBA or Internationl Institute of Business Analysis offers their own definition of the role.  To really understand their requirements I would have to purchase their BABOK guide.  I know more about the PMBOK material than whatever secrets this guide may hold.

So to wrap this up.  Yes, I think that a good Business Analyst adds value to the project team, even if it is using agile.  Just as a good Project Manager or a good Technical will.  In my mind the only time a BA is not an asset is if they are not particularly good at the job, in which case if the team has the bandwidth it may be able to make due without one.

I am, admittedly, a little biased. So what do you think?  Please leave a comment below and let me know what roles the Business Analysts play on your team and what value they add.  Does a Business Analyst add value on an Agile project?

Sustainable Projects

Sustainability is a word often used in relation to the environment.  To be sustainable a resource must be managed  so that the resource is not depleted or permanently damaged.  Most of us get this.  You cannot deplete the soil of all nutrients, hunt or fish and animal to extinction, or chop down every tree in a forest and expect to be able to continue on into the future.  Resources are not infinite, and a good resource manager knows that they must think about the long term use of a resource not just the short term.

What I don’t think people think about is that fact that people are, forgive me for saying this, resources.  At work we have Human Resources and People Resources, but workplaces don’t really think of people in the same way as they do other inputs to production.  Workers are often used on burnout levels at all times, especially on projects.  Companies want their projects done in the least amount of time possible, because projects are expensive.  Unfortunately the pace at which these projects proceed is not sustainable and for those of us that move from project to project we are constantly on the threshold for burnout.

I think projects should be designed with the idea that people are a renewable resource that you can either burn up quickly leaving nothing left, or you can allow time for that resource to renew itself and have more available in the long term.  This is especially important as the project mode of working becomes more ubiquitous in the workplace.  Breaks, reasonable work hours, and vacation time should all be worked into the project plan and even required on a project.  A project should  be given enough resources and be planned well enough that common practices such as the expected all night pushes before go-live, are no longer expected.

In an article I found on PM HUT, one of the 14 Key Principles grabbed my attention:

“Project managers must fight for time to do things right. In our work with project managers we often hear this complaint: “We always seem to have time to do the project over; I just wish we had taken the time to do it right in the first place!” Projects must have available enough time to “do it right the first time.” And project managers must fight for this time by demonstrating to sponsors and top managers why it’s necessary and how time spent will result in quality deliverables.”

This quote speaks to the same principle I am discussing here.  Doing things right takes time and team members that are not so burned out that they are making mistakes, having conflicts and disengaging in a way they would not normally.  It is important to instill the idea that while working hard and giving your all is expected, it is also expected that people will do what they need to in order to manage stress and remain healthy and productive.  This idea needs to be part of the team culture or it will not work.  This is important because otherwise everyone will skip that 15 minute walk, lunch break etc. in order to not seem to be giving less to the project than that one person who refuses to leave their desk.

Some of the biggest and best companies out there understand this principle and this is reflected in their workplace culture that seeks to actively provide for their employees well being beyond their paychecks.  While I don’t expect that all workplaces will install pool tables and give paid sabbaticals, project human resource sustainability is within the reach of all workplaces.

Image via Pinterest

3 Tips for the Small Business Project Manager

Working as a project manager for a small business seems like it would be an interesting experience.  According to Neil Posanansky, a small business environment is both exciting and demanding to the point of being overwhelming.

The project manager in a small business takes on many roles that they would not normally in a large business, such as coordinator and analyst, in addition to the manager role.  The PM may be juggling multiple projects simultaneously and may be working with ever changing team members as the business grows.

Neil gives some advice on how to tackle the challenges of project management in a small business environment that I break down into 3 tips.

1)  Adapt PMBOK Methodologies

Even though the project management methodology in the PMBOK focuses on larger businesses that are assumed to have more resources at their disposal these tools can still be adapted for the small business.  For instance, a change process can be very effective for controlling cost and scope even if it is very simple.

2)  Teach Team Skills

It is up to the project manager to teach the team how to work effectively as one.  This includes the role that each person is expected to take on the project and how that role effects the project.

3) Evolve

A small business project environment is one that is constantly changing and a PM must be able to innovate and adapt to it.

4 Entrepreneurs Discuss Project Management

In a short project management video by the Epson Business Council called “Small Business Project Management” I found some advice from a multinational group of entrepreneurs.

I like the emphasis made by a couple of the entrepreneurs that for a small business it is important to be flexible with employees on how they get the job done while being very clear on what should be done and and when it should be completed.

The focus of the discussion is around the question, “How does effective project management work?”

Here is a recap of the main points discussed by each of the entrepreneurs:

Jo Farley (UK)  

Founder Green & Black’s organic chocolate company

As an entrepreneur Jo doesn’t have the luxury of doing project management in the same way as a large organization.   She says that she tells her employee to do the project at home. If the employee  doe it in the office they will get distracted by a million interruptions.  She tells them what she wants, where to look for the information, and then tells them to get back to her when the job is finished.

Alain Bosetti (France)

Multi-entrepreneur, Founder and President of the “Micro Enterprise Show”

Alain likes to do regular progress reviews maybe once a week.  He will have a 30 minute meeting and to go around the table to see if everyone has done the task or not, what the next task is, and who is responsible for it.

Dr. Hasso Kaempfe (Germany)

Micro Business Consultant and Former Chairman of the Board of Mast-Jägermeister AG

Dr. Kaempfe thinks it is important to have clear objectives, milestones, and a binding time frame.  He believes that you should have a team that is as small as possible with clear responsibilities for each team member.

Marco Montemagno (Italy)

Co-founder of internet and social media enterprise companies including Codice Internet

Marco agrees that clear milestones are important, but his main emphasis was that the goal is getting the job done.  It doesn’t matter to him how or where, the office or at home.   Who is responsible is very important.  If you do great recruiting you can find a person who can manage a project very well.

Do you have any tips on managing a project in a small business environment?  Please leave a comment in the comment section below.