Martin's BA Blog!

Presenters should be SMART

Martin Schedlbauer — Tue, 07 Feb 2012 18:06:51 +0000

I just saw Noah Dawson’s blog on WizIQ that professors should be SMART. Now as a professor, I was immediately intrigued. After all, I think of myself as being “smart”. Then, the capitalization of SMART got my BA side going: SMART = specific, measurable, etc…

Hmmm… I read his well written blog and it was about professors using SMARTBoards — you know the one’s that act as giant interactive touch surfaces. In fact, I use them myself when I delivery seminars and workshops — good stuff…

But, then it got me thinking. Maybe professors (and teacher, presenters, instructors) should be SMART — Specific, Measurable, Achievable, Relevant, Testable.

In fact, I would say that all presenters (including professors) should be:

specific in what they say
should state ideas that can be measured (or “proven”)
ask for for work that is achievable
present what is relevant to the topic at hand, and
make the ideas testable.

But, I do agree with his conclusions: presenters (and most definitely professors) are often too lazy to leverage all the resources they have at their disposal. Let’s be honest, building and delivering an interactive, engaging, and insightful presentation is difficult and exhausting; I guess to many presenters have more important things to do…

Analyzing Stakeholders

Martin Schedlbauer — Sun, 05 Feb 2012 18:14:21 +0000

Understanding and managing the stakeholders is a critical activity in successful project implementations and other initiatives. It is performed as soon as a business need has been recognized. It is a continuous effort that occurs throughout the initiative’s lifecycle.

Definition

A stakeholder is any person, group, team, or internal or external organization that is affected by the initiative, has influence over it, or is involved in constructing, deploying, or managing the solution.

Analysis Dimensions

Stakeholders should be evaluated along a number of dimensions:

Position within the organization
Role and responsibilities on the project
Needs, expectations, and requirements
Success criteria that they will use to judge the outcome of the initiative
Communication needs
Influence on the project, solution, or initiative
Attitude towards the initiative
Impact of the initiative on their role and responsibilities
Interest in the project, solution, or initiative

Impact, attitude, influence, and interest can be measured along a scale ranging from positive to negative.

Business Interactions

Stakeholders may not only be individuals but rather may be organizations within or outside a company, such as customers, vendors, suppliers, markets, regulatory bodies, and so forth. They may be teams, groups, or virtual organizations. Therefore, the interactions between organizational units must be defined and described. Such interactions are best visualized through a diagram.

Analysis Process

Stakeholders should be identified early in the project’s lifecycle to ensure that their needs, expectations, and requirements are uncovered, documented, and communicated.

Stakeholders can often be grouped into classes whenever possible to reduce the number of individual stakeholders. For large groups, a representative must be chosen. If no such representative can be found, then a surrogate must be appointed.

During the requirements gathering effort, those stakeholders affected by or with input to the requirements must be consulted.

Evaluating Stakeholders

Stakeholders should be continually assessed along four dimensions:

Attitude toward the project or initiative
Influence over the project or initiative
Impact from the project or initiative
Interest in the project or initiative

Assessing Attitude

The attitude towards the projects can be supportive or unsupportive. It is determined whether:

The solution will benefit them personally
The organization at large benefits from the initiative
The initiative curtails their power or influence
They believe that the project team capable of delivering the solution on time
They think that their input is valued
There needs are being addressed
They believe that their collaboration on the project will be supported by the organization
They might be directly or indirectly punished or disadvantaged by participating in the project
They trust the project sponsor and business analyst
They have a good rapport and relationship with the business analyst and project manager
They believe that the team members value and appreciate their participation

Analyzing Attitude

For each stakeholder, the business analyst must ask himself or herself from the perspective of the stakeholder:

Personal Benefit: There has to be a positive benefit to the stakeholder for them to be engaged; if there is no benefit, the stakeholder is less likely to participate in workshops, volunteer information, remain engaged throughout the lifecycle, and generally support the project.
Personal Threats: A solution, project, or initiative that somehow threatens the stakeholder affects their attitude negatively. For example, a stakeholder who loses their job or loses influence or power will be less supportive of the project.

Assessing Influence

The influence wielded by stakeholders on the project or initiative can range from strong to weak. Influence is determined by factors such as whether:

They can affect funding, make decisions affecting resources, or exert influence over others in power to make funding and resource decisions
They have authority to allocate funding or resources or cause others to do so
They can sway the project sponsor
Have sufficient influence to effectively affect a project’s funding, resources, or organizational support
They can positively or negatively affect the attitude of other stakeholders
They have domain knowledge or subject matter expertise that is critical to the project

Assessing Impact

A project may impact a stakeholder positively or negatively. Impact on the stakeholder is determined whether:

The project benefits them or their immediate organizational unit
They gain or lose power or influence within the organization

Assessing Interest

Stakeholders may be more or less interested in a project or initiative. Their interest is influence whether:

They will directly benefit from the project
They respect and trust the project team
They believe that the project team will deliver the solution

Monitoring Attitude, Influence, Impact, and Interest

The four dimensions of stakeholder analysis can be mapped in a number of different two-dimensional matrices in order to better understand the relationships and how the stakeholder needs to be managed. This can be an invaluable tool in stakeholder communication planning and in how much “care and feeding” is necessary for a specific stakeholder or stakeholder group.

Next time, we’ll look at some techniques for mapping stakeholders and using that to determine how to manage them. So, stay tuned…

How do you monitor and evaluate your stakeholders?

Tech Gear for the BA

Martin Schedlbauer — Mon, 16 Jan 2012 02:40:40 +0000

It’s hard to find the right “tech gear” to work as a BA. I like to write on whiteboards in meetings and prefer to take notes in a notebook. I don’t know, but there’s just something distracting about the clickety-clack of someone taking notes on a keyboard. But it sure is nice to have the notes neatly typed up and ready to send to everyone right after the meeting. So what’s a tech-savvy BA supposed to do…

I think I may have found the right combination after years of trying to find the “perfect” solution. I’ve tried Microsoft’s OneNote (great product!), but it does not work on my Mac or on my iPad. I also wanted something that I can use anywhere and that integrates with the way I work. So, here’s my gear:

Evernote
LiveScribe
Slate
iPad
iPhone

Evernote

While I used to really like OneNote, I can’t use it anymore since I switched to a Mac. It also does not work on the iPad. But I’ve discovered Evernote and it’s great (and free; thanks Evernote!). It works on my iPad, iPhone, Kindle Fire (Android), Mac, PC, Slate, and even through the web. The notes I take in one device are synchronized automatically to all of my other devices. So, if I take a note quickly on my iPad, I can then edit it on my Mac later.

The web clipping is a great feature: see an article on the web you like, clip it and it saves in Evernote; it even works within Zite — my preferred news magazine reader for the iPad.

Evernote also takes voice notes, so you can dictate or use it to record meetings. The Premium version has the ability to “transcribe” your voice notes into text, if you are into that.

LiveScribe

Now, there’s something to be said for taking hand written notes, particularly when you want to sketch something or draw a map, illustration, mindmap, etc. That’s hard to do on an iPad or a computer (except for my Slate, but more on that later.) I’ve discovered LiveScribe a couple of years ago, but I’ve never fully adopted it until now. I can take hand written notes on my LiveScribe notebook and the LiveScribe Pen records it in its memory along with voice if I so choose. The notes are then synchronized with my PC or Mac (whichever I choose to use) and then automatically into Evernote. I can even directly e-mail the notes as PDFs that contain the voice (if I choose that option).

Now I have hand written notes automatically synced to all my devices and integrated into a single electronic notebook.

Slate

I like to draw during presentations, but whiteboard space often at a premium. Drawing on the iPad is possible, but painful. Drawing with digitizing pens on a Windows Tablet PC was always great, but they were bulky and you could not use touch input requiring an external keyboard for any serious work. The Eee EP121 Slate from Asus fixed that. It is a Windows 7 tablet computer with a nice 12.1 screen and solid hardware: it has a capacitive touch screen and a Wacom digitizer. Now you can use a virtual keyboard (or an attached bluetooth keyboard for solid typing sessions), use multi-touch gestures like on the iPad, give great PowerPoint presentations, and write precise notes or draw intricate diagrams directly on the screen with a pen. And, again, all of it an be imported or directly done in Evernote resulting in immediate synchronization across all my devices.

Of course, my UML and other requirements and business analysis modeling tools work well on the Slate since it’s Windows 7.

iPad

Can’t live without my iPad; great output device, great hardware, solid engineering. Aside from using it for surfing the web and tons of productivity apps, I keep all of my PDF documents on my iPad which allowed me to stop carrying bags full of documents, manuals, books, printouts, etc. And, the sync with Evernote keeps all of my PC, Slate, Mac, and LiveScribe notes right at my touch. The Evernote app on the iPad (and iPhone for quick on-the-go notes and look-ups) is well done.

iPhone

I really like to use whiteboards in sessions whenever possible; it gets everyone engaged. But there’s always the issue of recording what you wrote. That’s when I take pictures of whiteboarding sessions on my iPhone as an Evernote picture note and it is automatically synced to my various devices. Evernote can record the entire sessions as a voice note which is then also available where I need it.

I also use my iPhone or iPad to often record quick voice notes when I have a thought and typing is just too much. I do that in Evernote and the voice note is available on all of my other devices when I have time to act on it.

So, that’s how I’ve worked during the past few months and it looks like I finally have a useable and effective combination of tools. What are you using to track your work? Have you used any of these tools and how have you found them. Share your insights with us!

A Look at Requirements

Martin Schedlbauer — Fri, 11 Nov 2011 01:47:04 +0000

In this blog we’ll take a look at requirements, particularly the different types of requirements described in the BABOK(r), and how to write them to be effective for implementation and testing. Let’s start by defining what a requirement is. Simply put, a requirement is a feature that a product or service must have in order to be useful. For example, two requirements for a customer relationship management system might be to allow users to update the payment terms for an account and to add new customers.

The IEEE Glossary of Software Engineering Terminology provides a more precise definition. The same definition is also used by the BABOK®. Both define a requirement as a

condition or capability needed by a user to solve a problem or achieve an objective.

condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.

documented representation of a condition or capability in (1) or (2).

Not all requirements are expressed at the same level of detail and specificity. Some might be high level requirements expressed by the business sponsor (e.g., reduce the cost of invoicing customers) while others might be very specific requirements that describe a function needed by a particular user (e.g., allow me to click on a customer name and then display that customer’s account history).

Requirements Classification

The BABOK® defines the following requirements types: business, stakeholder (or user), functional solution, non-functional (or quality of service), solution, constraint, and transition. Note that these terms are overloaded and have different meaning in different organizations. For example, a stakeholder requirement is often referred to as a business requirement in some organizations and a business requirement is sometimes called a business goal or project objective. Functional solution requirements are also often called technical requirements, detailed requirements, or system requirements. So, it is important to understand the semantics of the terms being used.

Business Requirement

A business requirement is a higher-level requirement that defines a business objective or goal for the project or initiative. For example, a business requirement for installing an asset-tracking system at a University might be to “reduce theft or misplacement of fixed assets by 10% each year.”

Business requirements describe the reasons for initiating a project. Each stakeholder requirement must be traceable back to a business requirement in order to be considered in-scope.

Stakeholder Requirement

A stakeholder requirement defines the need of a particular stakeholder, such as a project sponsor, end user, or regulatory body. These requirements are commonly defined through use cases as they describe how a stakeholder intends to interact with the solution. Stakeholder requirements define product features. For example, a stakeholder requirement for an asset-tracking system at a University might be to “allow IT Specialists to record fixed assets.”

Solution Requirement

Solution requirements describe specific characteristics of the solution both in terms of functionality and quality of service. Solution requirements are sub-classified into functional and non-functional requirements.

Functional Requirement

Functional solution requirements define details of the expected behavior of the solution. For example, a functional solution requirement for an asset-tracking system at a University might be to “display each asset’s ID, description, acquisition cost, current location, previous locations, and current responsible party.”

Non-Functional Requirement

A non-functional solution requirement defines a quality of service requirement such as those relating to speed, response time, throughput, usability, security, privacy, availability, and so forth. For example, a non-functional solution requirement for an asset-tracking system at a University might be to “display an asset’s current location and responsible party within 2 seconds after having its QR code scanned 90% of the time.”

Transition Requirement

Transition requirements express how the solution will be placed into service and how to transition from the current state of the organization to its future state. These requirements, unlike the others, are temporary and require that the solution exist. For example, a transition requirement for an asset-tracking system at a University might be to “enter asset information from the current file records into the asset-tracking system through manual data entry.”

SMART Requirements

Writing requirements that follow the SMART template is a good starting point. SMART requirements are specific, measurable, achievable, relevant, and testable. Note that there are alternate but equally valid definitions of SMART used in practice. SMART requirements apply equally to functional as well as non-functional (quality of service) requirements.

Specific

A good requirement is specific and does not rely on generic or vague terms and descriptions. It should be precise enough to avoid being misinterpreted and be non-compound. In other words, a requirements definition should state a single requirement, so conjunctions such as “and”, “or”, “except”, and so forth should be avoided. Split the requirement into several requirements if necessary.

Measurable

The requirement must specify a metric that can be measured. Common metrics are time, performance, response time, volume, and so forth.

Achievable

The requirement must be attainable; in other words it cannot state a condition or capability that cannot be implemented.

Relevant

The requirement must address some need and must be traceable back to a business objective. It must be relevant to the project. This attribute helps manage project scope by only considering requirements that address an actual objective.
As a challenge question ask the stakeholders: “If this requirement were not implemented, would we still be able to achieve all of our business objectives?” If the answer is yes, then the requirement is not relevant and should be considered out-of-scope (or at least low priority).

Examples of SMART Requirements

The online course registration portal shall allow students who register for courses but have an outstanding balance to pay the balance online using one or more U.S. bank issued Visa, MasterCard, or American Express credit cards as long as the outstanding balance is less than $1,000.

The asset tracking system shall allow users authorized to view report to generate an end-of-month report that includes a list of all currently deployed assets along with their last known locations and responsible parties’ full names.

Examples of Poor Requirements

Requirements that don’t meet the SMART guidelines tend to be poor and lead to issues meeting the business and end users needs. Here are some examples of requirements that are not SMART compliant.

The system shall produce a periodic report that displays all assets data.

Why is this requirement poor? It does not specify what periodic means and it wants all data. All is too generic and creating a test for that would be difficult. What should happen if new fields were added to the assets’ records? Would that invalidate that requirement? Can you devise a set of test scenarios that demonstrate that the asset tracking system meets these requirements fully?

The system shall provide immediate feedback when an assets’ bar code has been scanned to indicate a successful scan.

This requirement is poor because the term immediate is impossible to implement. There is always a lag between the time and stimulus occurs (the barcode scan) and an action happens (the lookup of the asset and the display of its data).

So that’s it for now. Tell us, how do you define requirements in your organization and how do you measure the effectiveness of requirements.

Keeping Creativity Going

Martin Schedlbauer — Wed, 09 Nov 2011 01:24:09 +0000

Love that quote in Bart Cleveland’s blog about how to keep creativity flowing:

” He said that when he lived up north, he learned quickly that a faucet that was not dripping was the sign of a frozen pipe in the near future.”

We really don’t take enough “time outs” from our daily work grind to step back and think about where we are going and whether what we are doing and how we do it is making sense. I too often hear my client lament that they are overworked and have too much to do. When I ask why they are doing all that, they always seem to reply with “Well, we’ve always done it that way” or “That’s the way we do things around here”. Now that doesn’t seem all that smart to me.

So take a time out once a week for 30 – 60 minutes. Get together with your colleagues that think about what you could do better. Discuss an article or some new set of tools. Get inspired. You may not be able to change your work environment right away, but you will feel refreshed and you never know what you can learn. How about a brown-bag lunch where you discuss some article or review a tool? Or read a book together ad discuss its impact. Love the new book about Steve Jobs by Walter Isaacson — very inspiring and very insightful.

One of the stories that Walter recounts in his book is about how Steve Jobs that said that he “invented” fonts for the Mac because he took a calligraphy course in College which inspired him. That inspiration led to a revolution in desktop user interfaces and created the desktop publishing industry. So learn something new everyday and take some “time outs”. You never know what inspiration you are going to get…

Tell us: have you taken time outs before? done off-sites just to think?

Common BA Questions

Martin Schedlbauer — Sun, 13 Feb 2011 01:50:14 +0000

In this month’s blog, I’ll address some of the more common questions I get from business analysts that are just starting out. So, in no particular order, here they are. Let us know what advice you would have for these newly minted BAs.

Do you have a suggestion on how to best estimate the BA time required for a project?

I do have some suggestions. A common strategy is to create a list of all of the BA artifacts that you think you will need to effectively perform your BA work and communicate the requirements. Then break those artifacts down into smaller deliverables — this creates a work breakdown structure (WBS). Then for each deliverable identify the activities you need to perform to get the deliverables done. Finally, estimate each activity in ideal person hours and then roll up into ideal person days. Once you have the ideal person days, multiply that number of days by your effectiveness rate — the actual percentage of time that you really get work done each day. Most of us get about 4-5 hours of real work done per day, the rest is spent in meetings and putting out fires.

Can you define the difference between Functional Requirements and Non-Functional Requirements in software development?

A functional requirement defines expected behavior of a software system. For example, a list of accounts that is sortable by date as well as alphabetically would constitute a functional requirement. A non-functional requirement defines how well a software system operates. This includes requirements that define scalability, security, privacy, usability, accessibility, etc. For example, requiring that the software be accessible to users with vision impairment or that it be usable on specific versions of web browsers would be instances of non-functional requirements.

I heard it is good to know about the subject you are collecting requirements, and over time you will. But what if you need a crash course lesson on a subject, what is the best way to do so?

This one’s a toughie. I generally feel that good BAs know about the business domain. This is useful when you talk to stakeholders as you understand the specific domain’s jargon and terminology. This makes the conversations more efficient and requirements gathering generally takes less time as the stakeholders don’t have to spend a lot of time explaining their business domain.

However, there’s a benefit to not knowing much about the domain — it forces the stakeholders to explain their business and in doing so they think more carefully about their needs. Also, stakeholders sometimes assume that the BA knows more about the business than they do and they actually leave out information because they think that you already know. This can easily lead to lots of covert assumptions and hidden requirements — not a good thing.

To learn more about a business you need to have a broad background and then talk to lots of people. For example, I do a lot of consulting in the life sciences area — pharmaceutical, healthcare, and medical device companies. I do not have a background in those fields and generally know little about my client’s business at first. But, I have a background in science and therefore can quickly learn what they do even when I don’t understand every detail. If you don’t have a background in the field, then take an introductory college course on the subject. I also browse the web a lot. On a recent project with a pharma client they were talking lots about assays, blots, and in vivo versus in vitro compound trials. So, off to wikipedia I went and within a few hours I was up to speed on those subjects — knowing enough to collect requirements, but not enough to do actual lab work in microbiology and pharmacology

It takes time and effort to prepare the business analysis. Can you give us some tips to encourage the company to understand the value on the BA’s role and responsibilities?

I generally don’t try to tell them that BA work is critical and important — they generally just don’t care. Instead I tell them all of the work we BAs do is optional, although leaving it out does expose the project to certain risks. I then state what the risks are, the consequences should the risks materialize, the likelihood of that happening based on previous projects, and what we could do to mitigate the risks.

For example, I recently worked at a client who wanted to purchase a new software package. I suggested that we might want to build some context models to understand how the COTS package fits into our overall software environment. I also proposed that we do some business process modeling to make sure that the package works within our process. They said at first that while that would be really nice and the right thing to do, they just don’t have the time. I told them that I understand. However, that would expose the organization to some risks. I then elaborated on the risks and added them to the project’s risk log. I also met with the stakeholders to review the risks.

I told them that not understanding how the new package has to link with software systems currently in use in the organization might cause data duplication, data re-entry, and perhaps even lost data. Are they willing to accept that risk? Are they willing to have people enter data more than once? Are they willing to carry that extra cost? If not, then we could do a context model and understand the system interfaces and with that mitigate that particular risk. How’d it go, you ask? Well, we built a context model and learned that bringing in the package would entail building about a half dozen data bridges and impact five other departments…

What are the career prospects of Business Analysts? And how does one break into the profession?

The career prospects overall are quite good, but if you are a new BA without any experience it will take a while to break into the field. Get training and don’t be afraid to take a different job to learn more about the business. For example, many BAs start as project managers, QA specialists, testers, trainers, technical writers, and programmers. Learn how to write requirements, hone your written and verbal communication skills, apply them to make your role more effective and soon you will get that break.

Many of the BAs that I have in my BA seminars and workshops have backgrounds in programming, software development, finance, accounting, management, testing, QA, technical writing, training, science, and so forth.

That’s it for now. We’ll attack more questions in the next installment. In the meantime, share with us your views. How did you get into Business Analysis? What is your background? How do you explain to others what you do and why it’s valuable?

Justify Documentation

Martin Schedlbauer — Wed, 28 Jul 2010 20:29:14 +0000

As Business Analysts we write a lot of documentation. Most of our documentation comes in the form of text, but many BAs have learned to augment their text documents with a variety of diagrams. The thing that bothers me though, is that too many BAs blindly follow prescribed templates for their requirements artifacts. Rarely do they ask how their requirements documents are being used by stakeholders, testers, and developers.

As a BA, you should always ask these questions of your audience in regards to your documentation:

How do you use the documentation that I provide?
What parts of the documentation do you read?
Do you find the diagrams useful and understandable?
What parts do you not look at? Why not?
What can I add to the documentation to get you the information you need?
Is printed documentation the most effective way to provide you with the information?
How do you get the missing information? Do you talk directly with users and stakeholders?
Could I help you do that?
Are our templates organized in the best way?
Does the same document work for different audiences (think business vs. development)?
What’s the consequence if I don’t write some particular document?

We need to justify why we write documentation, not simply follow some template because it’s always been done like that. Too many templates have a “one-size-fits-all” structure that won’t work for some projects. Question the documentation templates and find better ways of communicating your analysis insights.

I believe that we need to look beyond documents as a way of managing and communicating requirements. Too many of my clients still use principally Microsoft Word to track, store, manage, and communicate their requirements. Why not publish the requirements as a Wiki? Why not track the requirements in an actual requirements management tool or at least a database? Why not use the power of the Web and HTML to provide live links and cross references?

Tell us, how do you document your requirements? Do you produce different documents for different audiences? How do you manage these different versions? Do they find them useful? Do you ever ask your developers and vendors how they use your documentation and how you might improve them? Have you considered using Wikis as an alternative to sharing requirements?

Survey on Social Networking Tools

Martin Schedlbauer — Tue, 27 Jul 2010 16:38:14 +0000

I’m conducting a survey on the adoption of social networking tools by professional business analysts. Help me by completing the survey! Here’s the URL for the survey. It’ll take no more than 5 minutes — there are only 9 questions. Plus, you might win a free copy of my new book on business process modeling — perhaps that’ll push you over the edge

I’ll post the results once I have collected and analyzed the data — should be a couple of months.

How do you use social networking tools? Which ones have you found to be especially useful?

Project Origination Sources

Martin Schedlbauer — Mon, 21 Jun 2010 16:28:11 +0000

As BAs we need to know where projects originate so that we can pick the right techniques to apply to analysis and documentation. So, where do projects come from? Projects originate from many sources. They can come top-down, bottom-up, from the middle, or from the outside.

Senior management originates project needs based on their strategic goals and directions. This requires the development of business cases and using high-level requirements analysis strategies, such as business use cases, context analysis, and business benefit statements.

Click-level end-users are a frequent source of projects. They encounter problems with a system or a business process during their daily work and based on those complaints they force us to launch projects to repair those defects. Requirements catalogs, use cases, storyboarding, and prototyping work best for those situations.

Middle managers often need information to make decisions. They need reports and dashboards that consolidate data from different sources. For those types of projects use cases, context analysis, and prototyping work best as requirements analysis techniques.

Finally, many projects come from customer complaints, market changes, competitive landscape updates, and regulatory changes. Depending on what the changes are, different requirements analysis strategies will work. Commonly, SWOT analysis, Fishbone diagramming, brainstorming, and prototyping are well suited for these types of projects.

So, know where your project’s coming from — it’ll help you understand where it’s going, who you need to consult, and how to get there…

Are Too Many BAs Simply “Order-Takers”?

Martin Schedlbauer — Mon, 21 Jun 2010 14:18:49 +0000

There is an issue that I’ve heard from my clients consistently over the past few years. It’s that too many Business Analysts (BAs) simply act as “order takers”. They go to the business to get requirements and simply write down what the business says. To them that’s the job of the BA and that’s what requirements elicitation is all about. I disagree! Elicitation is more than that and the BAs job goes beyond order taking. We must advise the business and we must analyze the requirements.

For example, too often we are given a fixed scope, fixed deadline, and fixed resources even before the requirements are even conceived. We then try to “get the requirements” and then struggle how to fit them into the project’s constraint. That’s not analysis. We need to advise the business when the goals are unrealistic — we need to manage expectations. If the project’s scope can’t be done in the timeframe we’ve been given, then tell the business why it can’t be done and tell what can be done.

As a former CEO, I always provided my projects teams with a vision, an overall scope, a deadline, a budget, and resources. Good leaders put stakes in the ground. If you don’t then the project teams work without goals and they won’t focus — deadline and resource constraints force prioritization and efficiency. But, if my constraints were unrealistic, I expected my project teams to tell me as soon as they know. I also want to know what they can do within the budget and timeframe. I want them to analyze the problem — not just go off, grumble and complain, and then tell me in the end that they can’t get it done. After all, I have set marketing, sales, and client expectations. So, if you can’t meet the objectives, let me know right away — I’ll understand if you give me reasons.

Anyway, we need to act more as analysts and not simply take orders and then go off without helping the business understand what can and can’t be done. Keep in mind that business does not know how IT works; educate them, help them understand why some requirements might not be doable.