Skip to main content

Slaying the Dragon: Oldies but Goodies in an Agile World

Written by Elizabeth Larson on . Posted in Articles.

Attending the PMI Global Congress a couple of weeks ago reminded me that good ideas have staying power. There were several presentations on managing agile projects. As I listened, I was reminded of some of my past projects. Here are a few principles that have always worked for me and that can apply to agile projects.

Divide and Conquer

When I was first promoted to project manager, I was given a large new project to tackle. One of my colleagues told me that he was glad I was assigned the project. He said that he dreaded hearing of a new initiative, because he imagined a large dragon with its head peeking around the cubicle wall. I loved being a dragon slayer. I took that fire-breathing beast and cut it into several pieces, which we prioritized and completed more or less successfully. The “less” had more to do with not getting input from enough business subject matter experts, but the principle of breaking a large project into smaller chunks worked wonderfully.

The Project Management “what” vs. “how”

Deliverables have always counted more on my projects than activities and tasks. Deliverables focus on what needs to be done. Tasks provide actions – how each deliverable will be produced. In his Global Congress presentation, Why Agile Focuses on the Work-Breakdown-Structure and Frequent Communications, Clement J Goebel described the application of the Work Breakdown Structure (WBS) to the agile environment. I continue to believe that the deliverable WBS is one of the most useful concepts in the PMBOK, and I was delighted to hear how it applies to agile projects. As a project manager, I was the only one I knew who never used a Gantt chart. Sure I had activity lists, but each task was tied to a deliverable. A feature if you will.

Whose Project is it, anyhow?

I learned early in my project management career that trying to control scope was a losing battle – one I fought courageously, but never won. I learned that requirements, the basis of the project scope, needed to be prioritized by the business, not by me. On some agile projects features are prioritized by the role of the product owner, or business representative, not the acting project manager.

The Three “I’s.”

In the mid-90s I worked on a large project, one of the organization’s early “RAD” projects. RAD stood for Rapid Application Design/Development. We were trained by a consultant, who taught us the principle of the Three-I’s” – Iteration, Increment, and Involvement. We learned to do iterations, focusing on prototyping as a way to drive out requirements, although in all honesty, our iterations were more of a hybrid approach than is used today.  The increments were time boxes. Again, our time boxes were longer and looser than those today, but they certainly helped.

Perhaps the most important of the “I’s” was Involvement. We were fortunate, indeed, to have a full-time business expert move from her office in the merchandising department, where she was one of hundreds of buyers, to our IS area where our team was co-located. Her presence was invaluable to the project. Today we would probably call her the product owner, but we called her a BUC– Business User Coordinator.  She facilitated the requirements workshops, prototyping sessions, and user acceptance testing. As code was developed, she brought other client representatives into our area to show them prototypes and ensure they were on board with the new system. She participated in sponsor meetings, particularly when there was conflict between SMEs.

Our BUC worked in true partnership with the business analyst who ensured that the requirements were clear, that dependencies were taken into account, and that the design, code, and testing addressed the approved requirements. She also helped ensure that the interfacing systems and programs were completed, since there were many hundreds of programs that needed to be changed to accommodate the new system. There was virtually no conflict between these two roles. The term “collaborate” was not in our vernacular, but that’s exactly what they did.

Although the project was considered highly successful, one of the main missing ingredients had to do with me, the project manager. In retrospect, I should have spent more of my time removing obstacles (of which there were massive numbers) and let the team figure out how to get the project done. I should have worked for the team, instead of viewing the team as working for me.

Final thought. It seems to me that agile was built on some pretty solid principles, but these have been taken to a whole new level, vastly improving the software development process.

Don’t forget to leave your comments below

Elizabeth Larson, PMP, CBAP, CEO and Co-Principal of Watermark Learning (www.watermarklearning.com) has over 25 years of experience in business, project management, requirements analysis, business analysis and leadership. She has presented workshops, seminars, and presentations since 1996 to thousands of participants on three different continents. Elizabeth’s speaking history includes, PMI North American, EMEA, and Asia-Pacific Global Congresses, various chapters of PMI, and ProjectWorld and Business Analyst World. Elizabeth was the lead contributor to the PMBOK® Guide – Fourth Edition in the new Collect Requirements Section 5.1 and to the BABOK® Guide – 2.0 Chapter on Business Analysis Planning and Monitoring. Elizabeth has co-authored the CBAP Certification Study Guide and the Practitioner’s Guide to Requirements Planning, as well as industry articles that have been published worldwide. She can be reached at [email protected].

Change Management; What Exactly is Buy-In?

Written by Kelly Burroughs on . Posted in Articles. 1 Comment on Change Management; What Exactly is Buy-In?

When it comes to change management, the term ‘buy-in’ is tossed around the office like a baseball around the diamond in a pre-game warm-up. It is a term used to indicate the need to convince everyone to get on board the change train, as it is destined for great things. But I find this term funny, because it indicates the change has already been decided, the train is leaving and I better get on or…well stay behind. And then we wonder why there is resistance to change.

But what if change was not something that was imposed on people, but was something they themselves came up with?

So many times I have worked on a project where a decision is made at an executive level, and then announced to the business with a fancy PowerPoint slide show, a few bullets about what the benefits will bring, and the overall concluding message of “we are doing this regardless, so you better get on board”.  And then we wonder why there is resistance to the change. But the fact is, if you make the decision to change without first asking the people the change will affect most, chances are pretty good there will be a defensive and resistant reaction.

One example that comes to mind is a company that decided to reorganize the entire organization without telling the employees until a company wide meeting was called one morning. Employees shuffled in, took their seats and found staring back at them, a man dressed up in a bear costume and fireman’s helmet, there to put out the ‘fire’ (and make the PowerPoint presentation). Needless to say, the reaction from the employees was not a good one (and going into the many reasons why might just be another article all on its own). In the end the meeting was not a productive one and, in fact, put many employees on the defensive about their job security and their role within the company. Everyone left more confused than when they had  arrived, and nobody remembered any of the benefits listed within the PowerPoint presentation (but will probably remember the bear costume for life!).

But what happens if you skip the fancy PowerPoint slide show, and get the non-IT folk to come up with the idea in the first place? Would there still be resistance?

People have a tendency to want to own things – whether it be their house, car, yacht, or the job they perform on a day to day basis. Because to many people a job is a set of daily routines and procedures they have become accustomed to doing on a daily basis; and more than that, have become very good at.  To then introduce change into that daily routine without consulting or involving them, is the equivalent of stealing their car from their driveway and trading it in for something new, without asking them. Now some people might be happy with a new car, but many people would resist the new car and want their old one back. Maybe they wouldn’t like the colour because they didn’t pick it, or maybe they didn’t really want the upgrade to a sunroof because they once had a bad experience sticking their heads through one. Maybe they just did not like the fact that the decision to get a new car was not theirs. And there is no difference with change in the workplace.  If you just suddenly take something away from somebody and replace it with something that you may think is better, you can almost be guaranteed they will find something wrong with it, and NOT think it better.

So then, how should change be introduced?

How about driving the change from a lower level? With so many change initiatives coming from the top of an organization, you constantly have a top-down channel of communication, which often puts those on the bottom on the defensive. How many times have we heard in reaction to a change: “Why do we need that? What is wrong with the way I do my job now?’ But what if what if those who would be most affected by the change were approached at the start and asked things like:

  • So what currently holds you up in your job?
  • Is there anything you do now that is completely manual?
  • Is there anything in the current process that you think should be changed which might make it easier for you to do your job?
  • Would you like to be involved in looking at new software for what you do?

Would they then see it as change, or would they maybe see it as something they can own, or do, to improve their jobs?

To me, getting others in the business to see the issues, own the issues and then, because of it, want to be part of the solution is the key to incorporating change into a company. It is surprising how often people are willing to be a part of projects, if they are just given the chance to get in at the start. But to be just told they are on a project, which ultimately affects their job, is often times a setback right from the beginning.

There will always be those who think making the decision and then showing the fancy PowerPoint presentation with the benefits of the solution is the answer to introducing change. But to me, change should never have to be introduced to the business – it should be generated upwards from the business. Getting people to realize the problems themselves, and come up with the solution themselves, will almost always work because people take pride in what they own and want to make their ideas work. Because remember; there is very little difference between ‘change’ and being ‘creative’. The only difference lies in where the direction comes from. You tell somebody to do something and they cringe at ‘change’, but if you get them to come up with the idea themselves they are ‘creative’, and will take pride in being so.

Don’t forget to leave your comments below

Kelly Burroughs is a Business Analyst/Project Manager for Halsall Associates, a professional services engineering company. She has several years experience in implementing larger scale technology changes into businesses, as both a business analyst and a project manager. She can be reached at [email protected].

Top Ten Reasons You REALLY Do Need a Requirements Document

Written by David De Witt on . Posted in Articles.

I had the opportunity recently to write a tongue-in-cheek piece with the not-so-brief title Top Ten Reasons You Don’t Need a Requirements Document when upgrading software. At the conclusion of that article, I offered to provide a realistic counter-point — my list of ten reasons why you MUST have a requirements document in hand before you invest money in upgrading or purchasing software.

With all due respect to another and far better known David who offers his top ten lists much more frequently, here are my top ten reasons that creating a requirements document is in your best interests — and your organization’s:

1. Requirements are not features. You simply must know what your users must have to do their jobs. Distinguish thoughtfully and carefully between what is needed and what the vendor is offering. At the same time, you must be able to factor into the requirements documentation other considerations, such as budget limitations and regulatory constraints. You will need to train your users how to specify their requirements, which takes tact, training, and patience. A request usually starts with: “All I really need is..” and then wanders away. A vague or ambiguous statement — regardless of its intent — will consume user time, IT time and cause some other loss, such as the opportunity to do another project. This issue is methodology neutral: Agile methods will have the same problem if user time is not focused and users are not trained. You cannot fulfill the requirements until they’re precise and complete and you understand why they’re important to the business.

  1. Features are not requirements. Eliminate decisions made by squeaky wheels — sometimes referred to as “design by whine” — where the loudest department gets the most resources. Your goal is to make certain that business decisions made with regard to requirements (and their associated expenditures) will generate the return you’re expecting. Start by working backward, to match the problems solved with existing software to identify the problems that must be and can be solved only with new software. Don’t lose anything you have now that is essential to the business; it’s easy to forget “hidden” requirements that oftentimes are taken for granted or ignored.
  2. Work with your resources and manage with discipline. Developing an effective requirements document costs money and managing resources requires discipline. A politically expedient decision, even if it’s cost effective in the short run but is not the right decision in the long run, will cost time and money – eventually. From a strategic point of view, ask if the requirements process itself is going to cost more than it’s worth. You will find that using the enterprise requirements documentation process will help you avoid useless meetings, which saves time and money, but more about that later. When the appropriate constituents are communicating with each other, they accept the value of their participation because they can track the project’s payback to the entire organization.
  3. On-going documentation is essential. It’s necessary that you continue to manage your requirements, because sometimes internal departments continue to push for a project application or feature that was denied in the last upgrade or purchase. Perhaps it wasn’t worth the cost, or its payback wasn’t acceptable to the enterprise as a whole. By maintaining continuity in your requirements documentation, you can see why a prior request was denied. If the reason hasn’t changed, it’s likely there is no need to investigate it again — and you can avoid bringing in a “new” solution to solve an equally “new” problem. Referencing prior documentation also can help you eliminate ongoing costs for applications and hardware that are no longer used.
  4. Identify and understand the workarounds and desk drawer systems. You need to understand what in your current application made a workaround or desk drawer system an attractive solution. Then, make certain the upgrade eliminates these systems and their causes, with this caveat: You might learn, in the course of such an investigation, that a certain desk drawer system has a unique function or user, and that it’s best left alone.
  5. Focus your users’ attention. You want to learn from them what can be done better, faster or more efficiently, but realize that users don’t always know their current business needs. In fact, users at different levels of an organization have different perceptions of business needs, priority and urgency. They tend to segregate by department or management level, dismissing problems because “it’s not an IT issue.” However, an effective requirements document requires integration and impact analysis for all departments. Know, too, that the needs of other stakeholders (senior management, operations personnel and human resources, for example) must be considered. User frustration comes from asking for one thing, and receiving another; help them articulate their needs carefully and fully. When what a user asks for is not possible, feasible or within budget, say so, because unmet expectations foster dissatisfaction. Always ask, what’s the relative value of a new “requirement” to avoid spending $10 to save a dime?. And don’t forget: users take what they have for granted, so make sure it’s carried forward in the new request.
  6. Benefit from “outside” expertise. An objective outsider, can, will and should ask the questions an insider cannot. What works? What doesn’t? What frequent requests create problems because they’re difficult to meet with the existing application? That’s the outsider’s function; to have no vested interest in how the problem is solved. It’s a common pitfall in requirements documentation to describe a problem in terms of its supposed solution, which might not be the best, or most cost effective, approach. An outsider also can provide useful guidance on how to handle regulatory requirements that affect information systems but that most business people are not aware of, such as the prohibition against retail businesses retaining credit card numbers after a transaction.
  7. Consider your upgrade as an investment and apply metrics to it. A comprehensive requirements document will help you decide if the benefits of the new application or upgrade justify the cost. How much more productive can the organization be with the upgrade, compared to the current application? Track paybacks for projects and information assets to determine when to re-invest or stop further investment. It’s possible that an application was a good investment — at the time. When it was installed, perhaps it saved every one of your 5,000 clerks 30 minutes a day. But today, you have five clerks and it saves them three minutes a day. That feature probably isn’t worth the cost. And some stand-alone features — such as desktop publishing — aren’t needed now, thanks to the tools available in word processing applications.
  8. Save time. Reduce rework by spending time in the requirements gathering and analysis process, where it’s much cheaper to eliminate a “need” than realizing it costs too much (or isn’t cost effective) downstream in the design, development or application stage. Time invested in the initial steps of the process provides more time for decision making at the right time. More control of the process will help keep it moving; participants will know what to expect as you move from blue sky thinking to brainstorming to understanding to decision making. Tracking the results of your meetings will document what you’ve agreed to do and what you’ve agreed not to do and who made the decision.
  9. Save money. To start, you will eliminate ongoing costs for applications and hardware that your requirements information gathering tells you are used no longer. With the right subject matter experts and decision makers involved at the right time, you will not be able to move forward on ideas that sound promising but contain potentially expensive problems that would have to be solved later in the process, and at a greater cost. You will open many avenues to managing costs, whether it’s eliminating unnecessary systems, consolidating a value-added system or evaluating long-term versus short-term value. You might learn, for example, that in the year required to acquire and install a new system the opportunity to use it will disappear. One of the most promising benefits of developing enterprise requirements is the strong possibility you will establish standard solutions to many of your seemingly “unique” problems, obviating the need for custom solutions. And that can be a real time and money saver.

Posted on Dr. Dobb’s Journal at www.ddj.com/codetalk and available at www.nuevista.com

© Copyright 2009. David De Witte

Don’t forget to leave your comments below

 

 

David De Witt is Practice Director for NueVista Group’s Enterprise Requirements Management Practice, has more than 20 years experience in organizational leadership, management consulting and Information Systems optimization. NueVista’s Enterprise Requirements Management Practice helps an organization maximize the value of its most significant investments — information technology personnel, software and hardware. David’s industry expertise includes his extensive work in supply chain and third party logistics, financial services and telecommunications. He has mentored companies in their strategic planning and management of Information Systems, leading initiatives in IS department governance, business alignment, staffing, infrastructure development and regulatory compliance support and reporting. David De Witt is an Advisor to the College of Business, Indiana State University and a Phi Beta Kappa graduate of Furman University, Greenville, SC. He earned his Master’s degree and Doctorate at Tulane University. David can be reached at [email protected].

Secret Public BA Shames

Written by Marcos Ferrer on . Posted in Articles.

Without naming names I am going to describe a “situation” that I have been aware of as a BA, and the management decisions that were made in spite of any analysis (quick guess, oh brilliant reader – were they good decisions?).  My purpose is twofold:

  1. I hope that the “situations”, though not outed publicly, will recognize “themselves”, and decide to take action.
  2. I hope that BAs who read this column will weigh in on the ETHICS of being a BA in such situations – is there a threshold where “outing” a situation is ethically required?

Situation: 

A certain government agency (un-named) needed a system to collect money from certain parties, to be disbursed to other parties.  The money is real and the rules and laws involving accounting and auditing clearly apply.  The agency already had an accounting based system that performed the functionality, but had no bookkeepers or accountants to run it. The personnel assigned to run it complained constantly, and  the executive in charge decided to replace the system, instead of training the personnel in accounting.

The agency avoided being forced to apply accounting rules and laws by publicly declaring (to the overseeing government agencies) that the system to be built was not a financial system.

When the project began, (I was not involved directly), I was approached by the project manager and asked what I thought of the requirements approach.  I shared the thought that avoiding the overhead of scrutiny was a cost saving strategy in a government project, and the system still needed to perform accounting. Money was being collected and disbursed, and accounting is the name of the correct solution (at least, it has been since the Italians invented it in the fourteenth century).

I was basically kicked out of his office, and had no other involvement in this project, except once, when I was asked to a review meeting, and asked if the “reversal” of a reversal transaction, where multiple parties had already been paid, was actually “reversible” – had anyone tried to do this on paper?  I was told that this was all covered in the requirements (this was not true), so I dropped the questions.

When the project was completed, it did not do accounting, as planned, and the users hated it even more than the old system.  It was found that to issue checks, in many cases a DBA had to “poke” data directly into the system and print a check from that data.

Two Questions

  1. What, if anything, is a BA who is aware of such a situation required to do?
  2. What are the implications and consequences of “poking checks” and printing them in a money system?

NEXT MONTH – another situation – send yours, if you know of one!

Don’t forget to leave your comments below

Marcos Ferrer, CBAP has over 20 years experience in the practice of business analysis and the application of Information Technology for process improvement. Following graduation in 1983 from the University of Chicago, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in diverse industries. His recent projects include working requirements for the Veteran’s Administration, introducing BA practices at the Washington Suburban Sanitary Commission, and creating bowling industry models for NRG Bowl LLC. In November 2006, Marcos Ferrer is one of the first  CBAPs certified by the IIBA. He has served as an elected member of the DC-Metro chapter of the IIBA, most recently as President, and assisted in the writing of the BOK 2.0 test.

Why on Earth Would You Promote a Business Analyst?

Written by John Simpson on . Posted in Articles.

We have a recommendation.  Whether their official titles are Business Analyst, Product Intelligence Analyst, Requirements Analyst or something else, if they define and manage requirements as a core function of their jobs, then they are strong candidates for a promotion.  Think this is a crazy request during this bad, but they tell us, improving, economy?  Maybe it’s not such a bad idea at all!

Read on to understand the five reasons why senior executives at innovation-driven organizations are realizing how strategically important business analysts are to the overall success of their companies.  And, they are rewarding those who excel in this role.  We’ll leave it to the bosses to decide exactly how they want to spread the love – bonuses, parking spots or other perks are always nice.

In many places the Business Analyst role doesn’t get much appreciation, because its value is misunderstood or viewed just as a tactical role.  Let’s debunk those myths here by examining the important role the BA has throughout the organization.

They are Shepherds of Innovation

As you know, innovation isn’t just a hyper-buzzword.  Innovation is what customers demand, it’s what shareholders expect.  And it’s what helps fatten the coffers of most successful corporations. How many nights do you lie awake thinking about how to more effectively deliver innovative products to market faster than the competition?

As unsexy and tactical as “requirements management” sounds and maybe is perceived, it is the foundation of an organization’s ability to innovate.  As business analysts, these employees are your shepherds of innovation.  Try that sound bite out at your next company meeting and see how the morale and company culture changes to embrace this important function.

 Project Success Lives or Dies by Requirements Management.

This isn’t meant as a statement to create dramatic effect – study after study shows that the management of requirements is a top success factor.  If you work in an industry such as Aerospace, Medical Devices or Healthcare where safety isn’t optional, then requirements management is itself a mandated requirement.  Based on that, it seems reasonable to suggest that anyone who manages a function that’s this critical to the success of your company deserves some kudos.  For example, the newly published Business Analysis Benchmark Study by IAG Consulting highlights several major findings, including:

  • Companies with poor requirements, on average, spend $2.24 million more per project on strategic projects than those that employ requirements best practices.
  • Companies with poor requirements and business analysis capability have three project failures for every one project success.
  • Only 32% of companies employ practices that make the likelihood of project success “Probable.” The remaining 68% enter every project with an “Improbable” likelihood of success, even before they begin the project
  • Over 40% of the IT development budget for software, staff and external professional services will be consumed by poor requirements at the average company using average analysts. This requirements premium is avoided by organizations that consistently use best practices in business requirements when completing projects.

An Idea is Worth $0 Until it Becomes a Well-executed Requirement.

We see requirements as the glue that holds the entire innovation process together – from ideas to requirements to products.  So, without well-defined, well-managed and well-executed requirements, innovation simply doesn’t happen.  Good ideas don’t materialize, R&D investments go to waste and smart people get frustrated – all things that paralyze an organization.  Thus, an investment in requirements management and in this key role will yield a higher Return on Ideas – think of it as a new kind of ROI to go with the financial one.

They Save Your Company “a lot” of Time and Money.

Call it productivity. Call it efficiency.  Call it failure avoidance.  Whatever you want to call it, your business analysts save your company a lot of time and money.   How much is a lot? It can be a difficult thing to quantify precisely, but a lot is somewhere between “oodles” and “a truck load”. And we all have an idea how much that is!  How ever you measure it, when requirements get done properly, projects get delivered on time and products go to market faster.  And, last time we checked, those were two things that great companies and senior executives valued. A lot!

Chief Business Analyst Sounds Pretty Nice.

Meet the new Chief Business Analyst, time to make room at the executive table!  Should we get new business cards printed up?  We’re not kidding.  By championing the development of thousands of well-written requirements and collaboratively managing them throughout your innovation process, your staff of business analysts significantly impact the performance of your company every day.  And, that makes them a strategic asset.  Hmm, that sounds like a function worthy of a C-level executive.  We think CBA sounds pretty nice too.

References: http://www.iag.biz/resources/library/business-analysis-benchmark.html A summary of the Business Analysis Benchmark appeared in a recent Business Analyst Times. To reach it click http://www.batimes.com/component/content/article/106-articles/517-business-analysis-benchmark-the-path-to-success.html

Don’t forget to leave your comments below

John Simpson is director of customer outreach and marketing at Jama Software. John represents the voice of the customer in Jama’s product strategy and communications. He has over 12 years experience working at software technology companies including Microsoft, WebTrends and Omniture. In his spare time, he chases his three kids around and raises awareness for cancer research in his local community, Portland, OR. You can reach John at http://www.jamasoftware.com or follow him on Twitter at http://www.twitter.com/jamasoftware