The disconnect between IT departments or PMO’s and the rest of their organizations is infamous. Whereas the rest of a company seems to live and die by such business driving objectives as revenue and profit, IT organizations often seem like they live in a separate house, concerned more with delivery, often feeling like they’re undeservedly at the mercy of the whims of their business-focused counterparts.

Out of Balance

IT expert and writer Michael Gentle at CIO.com explains the problem this way:

“IT is unduly focused on the supply side of the equation, or the how… to the detriment of the demand side, or the what.”

IT teams are often the ones who suffer most from the by-products of this phenomenon. A PMO manager at a Florida hospital recently recalled:

“Demand planning was just killing us, and we had a larger than average attrition rate that was very bothersome and a lot of team members who just felt we weren’t looking forward enough and just a general feeling of being overwhelmed.”

Frustration. Ineffectiveness. Missed deadlines. And a company falling short of its business objectives. These are the symptoms of an IT department’s failure to balance supply and demand.

If a lack of balance between supply and demand is the root of this problem, then balance is the key to solving it—demand management.

The Ingredients of Effective Demand Management

Although the concept usually goes unnoticed in IT organizations, it isn’t as complicated as you might think. In fact, it is as simple in concept as our description above: controlling demand to match resources and vice versa, constantly keeping that see-saw balanced.

And always at the center of it all, deciding how much is just right, weeding out the dross, is your business objectives. To put this in more practical terms, we broke it down into seven ingredients that, when used together, create effective demand management:

1. Ability to capture demand

You can’t control demand unless you know how much demand you’re getting. This means not just the number of projects in your queue, but potential resource requirements on each of those projects.

If all of your work management is taking place in one system, this will be relatively easy. You’ve already got a database collecting data on the intake of new requests and the magnitude of those potential projects. It’s just a matter of pulling a report that lets you see these all at once.

But if you’re taking requests from every direction—via email, chat, a homegrown ticketing system, etc.—this is going to be a bit tougher. If you’re in this situation, you’ve probably found yourself having to admit that you don’t know exactly what your team is working on at any given time. Honestly, this is going to make it difficult to gauge what your demand is.

2. Clearly defined business objectives

As stated above, business objectives are the linchpin in this whole balancing act. They are the means by which you measure the value of projects. They’re the scale you use to weigh projects against each other when trying to determine how much demand to allow.

To work the way you need them to, business objectives can’t be confined to the executive board room; they have to be applicable down to the project manager level. Project managers and their teams should know exactly what the objectives mean.

3. Clearly defined criteria for acceptance

Business objectives need to be translated into criteria for the acceptance or rejection of requests. The clearer and the more applicable these criteria are, the lower your and your requestors’ frustration will be. Most importantly, it prevents you from having to reinvent the wheel every time a new request comes down the pipe.

So spell out your acceptance criteria. Make them strict enough to adequately control demand, and make sure everyone knows what they are. If possible, build these criteria into your work management system and automate them.

4. Quantifiable cost and benefit data

One criterion every PMO must have among their acceptance criteria is cost-benefit data. How much is a project expected to cost? How much will it make? Like any business decision, the decision to accept a new project must include a discussion of how that project will increase company profits, either by decreasing expenses or increasing revenues.

Not every requestor will be comfortable with this notion, especially those who are used to using more qualitative reasons. But hold your ground. Demand management requires tough love, and, in this case, that means pushing back on requestors and forcing them to get the cost-benefit data to prove that their request is in the best interest of the company and not just a pet project. If they can’t provide quantifiable cost-benefit data, their request was not the kind you should be investing resources in. And you’ve successfully limited your demand.

5. Visibility of resources at team and individual level

So you’re controlling your inflow of requests. Metaphorically speaking, you’ve carefully placed on the demand side of your scale the appropriate amount of projects, nothing extemporaneous. Now you need to take a look at your resources to ensure that your supply can match your demand.

You need to know where your team’s man hours are going and where they’ve been committed for the coming weeks. This needs to be visible at the team and individual level. Having this visibility will raise all the right questions:

• “Do I need more resources?”
• “How can I shift Resource A to help Resource B satisfy this demand?”
• “I can’t satisfy this demand and my resources are fixed. How can I make my criteria tougher to push back demand?”

6. Ability to see effects of unplanned work on current projects

Having worked in a PMO or IT department, you’ve surely learned by now that even the best-laid plans can be interrupted by the occasional curve ball out of left field. This unplanned demand is often driven by actual crises (Ex: “Our site server just crashed!”). But, just as often, it’s urgency is more imagined than real (Ex: “I need a new nameplate for my desk! Pronto! With unicorns carved into it!”). Not to worry. The process you’ve put in place will weed out the good from the ugly.

This process is easier, however, if you have tools that will show the effects of dropping ad hoc requests into your work queue. Some of the best work management solutions feature capacity planners that forecast how timelines and resources will have to shift and budgets may be affected by an unplanned request. Combining these tools with strong acceptance criteria can be especially powerful in controlling unplanned demand.

In conclusion, demand management is a fine art—that’s why so few succeed at it. You need visibility to pull off this balancing act. But with the right tool and a little teamwork between management and IT, an organization can transform its IT team from a fish out of water to a well-honed engine for business success.

Conflicting Priorities and Limited Resources are Brewing up a Big Storm in Healthcare.

Just a brief introduction, I’m Mike and I’ll be your guide as we navigate the roiling seas of conflicting healthcare priorities. A quick search on Google can provide all the information you care to have on my career, as well as some crummy pictures. But, as an overview, I provide security and project management consulting services in healthcare and have for the last fifteen years. I speak frequently on healthcare education and security topics and I have written many articles on healthcare and technology related issues that have run in multiple publications like CIO magazine, CNBC and American Medical News.

So, back to the healthcare priorities, what are they? Well, that’s part of the problem. There are so many priorities at the moment in the healthcare space, it’s almost impossible to get a clear direction. There is an alphabet soup of healthcare initiatives that are pressing down on the industry (HIPAA, HITECH, ARRA, ACA, HIE, HIX, ICD-10, Meaningful Use) that, like a tsunami, has engulfed all resources available in many organizations. By the way, if you would like for me to translate any of those acronyms and their healthcare impact, just ask in the comments below.

As a project manager and information security consultant in the healthcare industry, I’ve been exposed to both the projects on the business side of healthcare (telemedicine, outreach, EMR/EHR, PACS) as well as the security angle (HIPAA Final Rule, securing the business of healthcare). I truly understand the monumental task of project managers attempting to deliver solutions on time while balancing the significant security requirements on the other.

Healthcare providers already have an overwhelming workload when it comes to treating patients. Convincing them to sit down and write cogent business requirements, participate in project planning meetings, or have a cohesive project strategy is a tremendous challenge. You will find that effective communication skills and an eye for using the appropriate project management techniques will get you much farther than stubbornly sticking to a specific project methodology while you constantly tweak your PPM reports.

Simple Tools and Processes as well as Clear Communication.

What I aim to do within this space is to provide advice on how to effectively manage projects in this chaotic environment, summarize key trends in the industry and discuss security implications of all these initiatives and mandates. I will dispense some hopefully valuable advice on how to market and manage your projects while providing guidance on the HIPPA privacy and security restrictions of various initiatives.

In my next post, I am going to cover the upcoming turbulence in the healthcare market as a whole. Large hospitals are buying up smaller practices and smaller practices are rushing to make this happen. The manifold risks and uncertainties of operating under the Affordable Care Act are causing tremendous change in the industry. This will greatly impact the project management and security professions for which we will all need to be prepared.

Please sound off in the comments below if you have any questions! I look forward to being your resource for all things healthcare project management and security related.

Well, AtTask has officially been inducted into the “cool kids club” and we are not ashamed to admit that we are thrilled.  AtTask was one of three vendors to be included in the “Cool Vendors in CRM Marketing Applications, 2013” report by Garter, Inc.

Gartner states, “This year’s Cool Vendors in marketing applications provide more robust people and project management and distributed marketing capabilities, and a data-driven cross-channel marketing platform.”

So what could be better? Well, cool companies like Tommy Hilfiger, Harry & David, Red Bull, Workday, and GoPro use AtTask for marketing teams to bring visibility, communication, and harmony to their marketing teams.

So what are you looking for in a “cool” Enterprise Work Management tool?

Download the full Gartner report.

Additional Resources:

• Listen to how top marketers are solving communication and visibility problems
• Read how other marketing customers are using the AtTask
• Watch how AtTask can calm the chaos of marketing teams

Those who manage work and projects on a daily basis know expectation management is a key part of the work process which often gets poorly communicated, brushed aside, or confused with requirements management. Why? There are a number of reasons: because there is a looming deadline, because it seems easier, because it’s not an official part of the process. Or, it could be because the project leader doesn’t know how to manage expectations so they just hope for the best. It’s exactly this thinking that dooms productive, collaborative and efficient work.

In “Absolute Beginner’s Guide to Project Management,” Gregory M. Horine writes that expectations are shaped by both reality and perception:

“In an ideal project, both the reality and perception of project objectives, performance, targeted results, and expected impact are aligned up-front among all stakeholders during project definition and planning, and then remain this way throughout the project. However, this ideal situation generally eludes us.”

How can we achieve the ideal situation? By aligning the reality and perception of expectations through six best practices:

1. Know the difference between expectations and requirements. Technically, every requirement is also an expectation. This is because stakeholders expect requirements will be met. However, most of the time expectations refer to the part of the deliverable such as design, user experience, reliability, and other subjective pieces that are hard to document and even harder to get a clear picture of from the stakeholders. Stakeholders like to measure the effectiveness of expectations by how they feel about them more than ticking a box that it was “done.” In short, the definition of requirements versus expectations is that requirements are objectively stated and clearly defined, and expectations are subjective and loosely understood. (In addition, it is critical to know the difference between the product and project expectations as well. That’s something we covered here.)

2. Have a kick off with stakeholders and discuss the expectations. It is important to take enough time to ask the right questions and get the right people to respond. The way to do this is to get buy in as early as possible from all parties at a kickoff meeting. Those involved can sign off—and be witnessed signing off—on what the product is (requirements) and how it works (expectations). If you do this, your job as a manager during execution will be more focused on delivery of requirements than detective work about unknown or unforeseen expectations.

It may even help to hold a separate meeting altogether for requirements. Once a frank discussion is had about the subjective elements of the product or project, you can talk about which expectations might be problematic, either to define or to meet. This will get you closer to alignment from stakeholders and you can feel better about the potential your project has to succeed.

3. Realize you will not meet every expectation. Stakeholders will always show up with their own distinct yet varied sets of expectations. Of course, many will be impossible to achieve in the timeline given with the resources at your disposal. This is common. One solution is to have a discussion that paints the reality of the various realistic and unrealistic requests. You may still be asked to go “above and beyond” but, with the potential problems of the unrealistic expectations documented clearly upfront, there will be no surprises. This is also a good exercise for confirming which stakeholder expectations carry greater influence and priority.

Once this is done, your job as a manager is to mold expectations as the project progresses. Doing this means finding out during approval stages what will satisfy stakeholders, not what will be perfect for them. Again, this will probably mean compromise but, as long as the implications of a stakeholder request are clear (lack of UI, pushed deadline, more money), you will find expectations being met through what is acceptable, leading to less objections about the same thing. You can always refer back to the “realistic versus unrealistic” discussion as back up, which is one of the benefits of getting everything done at the kick off in writing.

4. Have a defined project communication plan. This means frequent disclosure to all stakeholders. Assumptions will kill your team, your work, and your deadline. You know what they say about the word “assume.” Developing a communication plan that errs on the side of over-communication will be critical to the success of your project and work objectives. This is a plan that will set context for communicating with the team and stakeholders about both requirements and expectations. It will outline:

• How reporting will be done
• How often updates will be ready
• How changes will be addressed
• How disagreements will handled
• Who has what role and when to talk to that person

The most important step of creating this communication plan, much like the kick off, is that it’s agreed to upfront.

With the above in order, you can be the right amount of good cop and bad cop to see your team’s work through to completion. Stick to the communication plan like glue. Over communicate the overarching “why this is important” so everyone understands how crucial their role really is.

“Your ability to manage the perceptions of each individual associated with the project is the key to managing expectations,” writes Horine.

5. Always expect change. Your project will change. Even when you’ve planned everything perfectly, it will change. Look and listen for cues that you have a frustrated or unaligned team member or stakeholder and set up a time to iron it out quickly.

Robert Bell, in a post titled “How to Proactively Manage Project Expectations,” writes that teams will probably need to compromise and make emergency changes along the way. Changes are fine as long as both the team and stakeholders know about it and sign off on it. He explains that when things are tough and a tight deadline is looming, everyone needs to know what’s happening and whether there will be any changes to the agreed upon requirements and expectations.

As a leader, develop the ability to see things from others’ perspectives. This will help you anticipate needs and concerns and showcases you as the flexible one. This is a skill that will allow you to adapt to best handle the situation at hand.

The most important takeaway is that making stakeholders a part of your work process will give you more time to focus on getting the work done on time rather than worrying about when they will throw the next wrench into your plan.

What are some of the ways you’ve managed expectations during projects?

To learn more about a way to easily incorporate stakeholders into your team’s work processes, click here.

There is a difference between building every feature and building the right feature. (Image: edocumentsciences.com)

Henry Ford is apocryphally quoted as saying: “If I had asked people what they wanted, they’d have said faster horses.”

On the other hand, the legendary David Ogilvy said: “Advertising people who ignore research are as dangerous as generals who ignore decodes of enemy signals.”

Which approach is right? In reality, neither guy was as one-sided as their famous quotes imply. Just like advertising and car design decades before, the software industry struggles to balance inspired creativity while specifically meeting the established work needs and patterns of existing customers.

So how does a well-run software company figure out what to build? Every company will have unique challenges but most strong enterprise product groups follow a process similar to the one we follow here at AtTask. We collect as much information as we can, mix in new trends and inspiration with care, and aim for a balanced approach.

There are a ton of information sources available to us as a software company and we try to take advantage of them all. We group our sources into three main categories which we lean on to get great concepts to make our solution better.

Internal guidance. This represents all the things we can find out from our internal information. The corporate goals and strategy of the company fall into this area. So does feedback from our sales department about why we won or lost the deals they pursued. A less obvious but also valuable source is our ability to look at the actual usage patterns of AtTask by our customers. We can see which parts of the program get lots of use, which are middle of the road, and which parts are the little-visited backwaters.

Direct customer feedback. The second category is probably the one that comes to mind first. We are fortunate enough to have more than 1000 AtTask Research Community members who take part in surveys and send ideas to us. We get ideas continually all year and review them on a weekly basis. Additionally, we have daily phone calls with customers, weekly sync-ups with our consulting teams, and daily “heartbeats” with support to stay in touch with what our customers are reaching out to tell us.

External insights. All of us in product management are geeky enough to actually think it is fun to stay up to date on industry trends, hot companies that are launching, and new technologies that will shape the future. We constantly scan the landscape for inspiration and ideas. Additionally, we pack our bags and go visit customers to conduct contextual inquiries which means watching people work in our (or another) system, being careful not to influence them and learning as much as we can. We also have regular reviews with analyst firms like Forrester, Gartner, and IDC among others.

Once we have the suggestions, ideas, and information from these sources we:

• Continually update a backlog of possible enhancements.
• Gauge the level of effort required by development for each item.
• Estimate how much development time is available.
• Plan to do as much as we can of the highest priority items on the list.

The battle for which features get into the next round of development and what has to wait can be hard fought. It can really be agonizing to choose what has to be left out knowing that there are people with real needs behind each suggestion. The possible improvements for a complex application are limitless while development time and sanity are not. All companies like ours struggle to find the perfect balance for our customers.

It’s a never-ending struggle but as we continue to grow, it will remain an important pillar for improving our solution along the way.

To learn more about AtTask, click here.

In this second post in a four-part series, I’ll write about Change Management.

One of the many things that differentiates AtTask from others is that we get that there is a change management aspect to your rollout. Many customers are embarking on improving their process through a supporting tool that helps them improve how they operate. Every day I talk to someone that wants to know how we help as part of an AtTask implementation.

Our consultants are PMP or Prince2 certified. This helps ensure that they have documented 1000s of hours managing projects. That means they can help with your AtTask project, but also with how projects operate in your organization. Additionally, many of our consultants have created and/or managed a PMO giving them additional relevant experience. Another item we focus on is industry expertise. Our consultants have commonly helped multiple customers in your direct market area so they bring experience how other customers like you have overcome challenges. And finally, with their AtTask certification and application experiences they have deployed AtTask a lot and, in some cases, hundreds of times.

So how does all of this help your team?

Simple, we are more than application experts. We face these challenges in our careers and in our every day life. We can help your team develop exercises and activities to get people using the new processes. We are also familiar with the common myths and fears faced in a changing and maturing environment.

You ever wonder why people fear a change to begin implementing timesheets? It’s because many do not take the time to demonstrate how the end-user logging time will help the manager set better service levels for customers, or justify headcount, or get better about changing priorities.

With AtTask Services, you get more than the AtTask Expert. You get someone who has been there, done that, and can help your team overcome the challenges of change.

Resource Management is the master card for those whose job it is to manage teams and multiple projects that impact a company’s bottom line. This is sometimes referred to as ‘people planning’ but it really entails planning, managing, and assigning the right people, with the right skills, at the right time to the right projects. In today’s fast-paced, need-it-now, bigger-than-the-last-time world of business, a pair of twos just isn’t good enough. The point is, keeping people busy isn’t a problem. Keeping them on the right work is.

Successful resource management can be broken down into three critical disciplines:

• Demand Management involves the work intake, demand forecasting, and estimation part of the process.
• Capacity Management covers rolls and skills management, capacity planning, resource assignment, and alternative sourcing.
• Time Management involves time tracking and analysis to better gauge estimates.

These three disciplines cannot operate independently. There is overlap in each one and, in order to be successful with resource management, you must give adequate attention to all three.

Here are five ways to make sure you stay on top of all three disciplines so you can be well on your way to a resource management winner.

 1. Know and Prioritize the Work

• It is important to inventory the work you know about and estimate the work you don’t.
• There should be a grouping process for evaluating and prioritizing each type of request. What you don’t want to do is to apply the same level of rigor to every type of work.
• In 2010, only 40% of organizations reported having a functioning enterprise resource allocation process.
• Don’t ignore the benefits of automation. Create a mechanism to generate a complete view of demand.

2. Know Team Strengths and Limitations

• In order to gain a complete overview of resource availability you need to know where resources are committed.
• Understand the roles and skills of each individual to optimize assignments. Don’t view resources as “buckets” of time with equal capabilities. Individuals have particular strengths, i.e., what they are good at and can do quickly.
• Don’t assume your team’s capacity won’t change over time. What they’re capable of now will likely increase.
• Multi-tasking results in 66 % longer average project time so be mindful of current assignments when resourcing.
• It’s also important to recognize that a 40-hour workweek does not consist of 40 hours. Allow time for ad-hoc, lights-on, and other types of work.

3. Right People, Right Job, Right Time

• This one is key. Develop priorities early and categorize work based on alignment.
• It’s important to not forecast resources in a vacuum. It will be tendency to turn to your superstars over and over again; those individuals you can count on to get the work done no matter what. Do not overuse them.
• Negotiate job load to avoid burnout or risk losing those who you value most.
• Have a process in place to supplement staff if necessary. When you take a reactive approach to augmenting staff it may be too late by the time you get around to doing something about it.
• Maintaining some resource reserves is ideal for handling the inevitable constant change. Reserve capacity is a must when facing complex project or program situations.

4. Use Time Tracking Appropriately

• Time tracking can be a touchy topic. Be prepared for the challenges that accompany time tracking implementation.
• Be sure and keep it at an appropriate or comfortable level. The goal is to better understand where the resources availability is, not to play big brother.
• Evaluate and select a tool to simplify time entry. No, post-it notes do not count.
• You’ll want to make sure your tracking is accurate and complete so that when you analyze the data you can refine your estimates and use that information to drive improvements.
• 34% of projects in 2010 were in a queue or backlog, implying that projects are waiting for people, because people are over-allocated.

5. Plan For Change and Don’t Change Your Plan

• Setup initial and ongoing change management processes and make sure to adhere to them. The temptation will be to let “just this one change” slip in. Stick to your guns.
• Also, you don’t want to build a change management process that isn’t scalable.

Using these five best practices will undoubtedly improve your team’s efficiency. Which is a big deal considering 49% of enterprise teams put high priority on improving efficiency. Increased efficiency will drive innovation and 70% of enterprises claim increased innovation is their top priority.

Putting the right people on the right job at the right time is not a new concept but certainly one that deserves some attention. Resource management may not be as sexy as winning a hand in high stakes poker but remembering these important tips will make you an invaluable Ace your executive will keep up their sleeve.

To take your resource management skills to the next level check out AtTask Enterprise Work Cloud here.

Client work v. company application development. What’s best for you? (Image: iconarchive.com)

Programming jobs come in many different shapes and sizes. At some companies, you’re the programmer guy, the IT guy, or the anything-remotely-related-to-computers guy. At other companies, you’re one of several dozen developers maintaining a single, thin layer of code within a huge system. In general, programming jobs fall into one of two camps:

• Consulting work for clients
• Application development for one company

The client work camp consists primarily of tiny to mid-sized companies that will do contract work for different customers. In the other camp you will see mid- to large-sized companies that have an application or suite of apps that they sell to others.

It’s important that you work in the right camp for you, unless you enjoy pulling your hair out every day. Each side has its own set of perks, but will also come with its own set of baggage. Here are the best and worst of each.

Application Development

The Best:

• Depth – When you’re always working on the same product, you can (hopefully!) get around to fixing all the annoying things you see in the code. Optimization is emphasized, and you can go to sleep at night knowing that your code is solid.
• Stability – It’s easy for a company that only manages one application to plan ahead and provide a road map for its developers. You can always get a sense of where the product is headed and what you’ll be working on in the coming year.
• (Lack of) Customer Interaction – We always love our customers, or whoever is willing to pay us money for our work, but developers are typically not the best “people” people. Most companies that manage a big application will also have customer service departments to do all that work for you.

The Worst:

• Bugs – Since you’re always working on the same application, the bugs don’t go away. Just because you’ve moved on to another project doesn’t mean you are no longer responsible for code you’ve written in the past. This can wear on you.
• Legacy Code – You’re never the first one in the code, and the developers who were there before you never seem to do it quite the way you wanted them to. Finding bad code (and complaining about it) is a common occurrence.

Client Work

The Best:

• Always New – Don’t like what you’re working on? No problem! You’ll be working on something completely different in no more than a few months, so just hang in there. There’s always another client with another project just around the corner.
• Cowboy Coding – Since you can basically start from scratch with each new client (sometimes), that gives you a lot of leeway to try new things and do them your way. Experimenting with new technologies is much easier this way.
• No Bugs! – Once the project is complete and the client signs off, you don’t have to touch any of that code again (not for free, anyway). Not that you want to write fickle code, but there isn’t nearly as much pressure on you to produce fully optimized work.

The Worst:

• Customer Interaction – On the flipside of application development, developers will frequently talk to/work with the client directly. This can be very frustrating when you learn that they don’t know the first thing about computers and they don’t understand anything you’re saying to them.
• Instability – If your company relies on contract work for clients, then it’s very difficult to see farther than six months away. This can lead to a lot of unneeded stress around the office.

At the end of the day, one camp is not superior to the other. But before you jump on the next job offer you get, make sure you know which camp is right for you.

To learn more about AtTask and if it’s the right company for you, click here.

Aside from the whole communication issue, change should come with this warning:

Have you properly defined your use of the word change in this conversation?

It’s critical in management of any sort, be it project, line, tactical or strategic, to make sure your audience understands the type of change that’s either in progress or is coming.

Because I’m blogging about business change from an IT project perspective I thought we’d start by identifying some typical change related terms and their definitions. These terms apply to every IT project I’ve ever heard about or been involved with and have seen first hand how clarity benefits everyone. First, let’s get the Oxford Online Dictionary’s definition of change, just so we’re clear where we’re starting: Change as a verb:

• To make or become different, eg: a proposal to change the project scope
• Take or use another instead of, eg: the sponsor decided to change the projects name

Change as a noun:

• an act or process through which something becomes different, eg: the change from a local to a globally strategic project

Now let’s take a look at other common terms used that mean change:

• Transition – the process or a period of changing from one state or condition to another, eg: the project closedown included the transition of new system run processes across to daily IT operations.

• Transformation – a marked change in form, nature or appearance, eg: the new Sponsor ensured the program underwent a radical transformation.

• Change Management – the management of change and development within a business or similar organization. The controlled identification and implementation of required changes within an IT system or software, eg: the process, rigour and governance applied to a merger and acquisition or software or hardware upgrade.

• Business process re-engineering (BPR) – the process of restructuring business-as-usual processes and methods. Particularly relevant when exploiting the capabilities expected from an IT project.

Do you use these terms in your projects? What other terms do you hear bandied about? In what context are they used and what do they really mean? I think ‘change’ is suffering from OOS (Occupational Overuse Syndrome). I also believe we as responsible professional Project Managers have an opportunity to take ownership and help an organisation simplify its use by bringing more clarity to change in our projects. Do you agree?

This house isn’t going anywhere!

For most of my life, I dreamed of being an architect. I’m a creative to the core and in high school I loved my art, drafting, AutoCAD, and architectural drawing classes. But I was really only interested in the drawing and design part of it. In reality, there were many things I never considered about architecture like how much math was going to be involved and all of the logistics. I had never thought a thing about the necessity of designing solid foundations for the structures I was designing which is basically construction 101. In order to build a sturdy structure, you have to start with a strong foundation.

The same principle applies to any work or project management. In order to create a successful project and deliver a quality product, you have to start by building your project plan on a firm foundation. That foundation is created by gathering project requirements. Too many project managers either overlook the importance of requirements management or fail to understand the difference between scope, requirements, and expectations. In fact, 60-80 percent of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group, now a part of Gartner). G. Chandrashekar of the ProjectSmart blog wrote,

“Innumerable studies have shown that requirements gathering is the single most important step…It’s far more expensive to fix a requirements error than a coding error. But somehow everyone seems to believe that a requirements specification document is the easiest part to produce…It can’t be further from the truth. No one ever built a good structure without the right foundation. Make sure that you take time to gather the requirements fully and analyse them in depth.”

If you’re interested in helping your projects succeed, here are five important things about requirements management you should know:

1. Gathering requirements comes first, defining scope comes second. It is fairly common in the project management world for people to use the terms “requirements” and “scope” synonymously. But they are different. Requirements are the demands, needs, and specifications for a product as outlined by project stakeholders. The Deep Fried Brain Blog defines requirements as what the customer needs. Requirements can also be many types. They can be product related requirements, performance requirements, quality requirements, project management requirements, etc.

For example, if the requested product is a house, stakeholders may require that the finished product include four bedrooms, two and a half bathrooms, two stories, white walls, and an island in the kitchen. Requirements can also include specific budgets and timelines—any demand that is definable and considered an “absolute must.”

After all the stakeholder’s requirements have been collected and clarified you can start to define the scope. The scope sets the boundaries, or constraints, for the product. For example, you may need to build a house with four bedrooms and two stories, but because of the size of the plot of land, you have to do it without exceeding a scope of 1500 square feet of built up area, or a budget of $200,000. It’s important to gather and define all the stakeholder requirements first so you can make sure that the requirements are doable within the scope agreed upon. If building four bedrooms will cause you to exceed the scope, you will need to go back to your stakeholders and either try to redefine the requirements, or set new expectations: Okay, we can do four bedrooms, but they are going to be 4 square feet smaller than you expected if we are to stay within scope. Will that work? 

2. There are two types of requirements: project requirements and product requirements. Understand that as a project manager, you will be expected to manage your project requirements and your product requirements. The CDC Unified Process Practices Guide outlines the distinction like this:

• Project Requirements define how the work will be managed. This includes the budget, communication management, resource management, quality assurance, risk management, and scope management. Project requirements focus on who, when, where, and how something gets done. Project requirements are generally documented in the Project Management Plan.

• Product Requirements include high level features or capabilities that the business team has committed to delivering to a customer. Product requirements do not specify how the features or the capabilities will be designed.

3. Make sure you adequately document all the requirements. This is another common mistake among project managers that can have catastrophic results. When you have your initial kick-off meeting to gather requirements, make sure that you document everything and keep it in a central location. When ever you have a status meeting, refer back to the documented requirements to remind stakeholders of the original agreements. This way, if they think of additional requirements or accuse you of missing a requirement mid-project, you can point to your documentation and have a discussion from there about what implementing this new require will entail and how it will affect outcomes, scope, etc.

As Chandrashekar puts it,

“During the requirements gathering you get a huge amount of data, often in disparate forms. Word documents, spreadsheets, PowerPoint presentations, image files. The list is endless. Document, index and retain every bit of information you come across using a good software tool. Ask everyone in the project to document everything in a centralised database, not on their desktops.”

4. Ask for as much detail as possible. Remember, detail is your best friend when it comes to gathering requirements. Often, if project managers do not “dig deep” and ask lots of questions to clarify the details of a requirement, they end up with misunderstandings. The problem is, different people can interpret different requirements in different ways. The more questions you ask and the more specific you get, the better off you’ll be. Chandrashekar explains that everyone will interpret it based on their own knowledge and experience and that there’s no way to insure against getting the interpretation wrong. Getting the big picture right is important but so are the minute details. For example, if a stakeholder requires that the house has white walls, make sure to ask if that means all of the walls, or only some of the walls. Also clarify if they have a specific brand of paint they require. Ask if they want bright white or eggshell. These details may seem tedious and even silly, but asking specific questions and getting as detailed as possible will help you to meet your stakeholder’s requirements and their expectations.

5. Sometimes, stakeholders will have expectations that conflict with the requirements. Finally, keep in mind that, when somebody requests a product from you, they may trust you to get it done, but they still have their own idea of how they want the completed product to look, act, feel, perform, etc. This is another reason it’s important for you to get as many details as you can when gathering requirements—because it helps you understand the stakeholder’s expectations that they may not have even know they had. It’s common during the process of a project to discover new expectations that don’t align with the originally documented requirements. For example, a stakeholder could say something like, “Oh I thought this room was going to have vaulted ceilings.” Though they are disappointed because they had that expectation, you can politely direct them back to the original requirements and reply, “That wouldn’t work because so-and-so required this house to be two stories.” If you always have specific requirements that are well documented and you communicate regularly, you will either be able to reset their expectations or find a way to incorporate their expectations—when it doesn’t cause you to exceed budget or move outside of the project scope.

If you’re able to remember these five things when managing requirements, you will be better able to create project foundations on which you can build solid products and have more successful project outcomes.

CLICK HERE for more information on software that can help you manage project requirements in a central location.