Skip to main content

Tag: Software

Don’t Be An SDLC Extremist!

  • Do you follow process as a Fan or Fanatic?
  • Are you a Loyalist or a Zealot?
  • Are your suggestions Revolutionizing or Revolting?

In the 1980s Pepsi was tired of hearing that people prefer the taste of Coca-Cola over Pepsi. So they came up with the Pepsi Challenge. It was genius, and the results surprised more than those that were blindfolded. Characters in the ads always picked Pepsi, of course, but so did most people who tried it in real life—the sweeter taste was more appealing. So how did Coca-Cola keep their market share and brand loyalty? People continued to have positive feelings toward Cola-Cola, not because of the flavor of their soft drink or because they had a better product, but because they were loyal to the brand.

I wish there was a blind taste test for Software Development Lifecycle Methodologies, so people can see that SDLCs are not so different after all!

Diehard sports fans are the same way. When I was growing up the New Orleans Football Team was lovingly referred to as the ‘Aints’ as in “They AIN’T ever gonna make it to the Super Bowl.” So how did the Superdome get sold out Sunday after Sunday? Because Saints Fans were proud of their team whether they won or lost! No matter the projections, the odds, or the score a Saints fan would fight tooth and nail to defend their team.

I wish there was a super bowl for SDLC so we would know which SDLC has the most success.

Heaven’s Gate was an American UFO religious group from California. They believed that the earth was going to be “recycled” meaning wiped clean. They believed that the only way to survive was to leave the planet – that a spacecraft was trailing the comet Hale-Bopp. A large group of followers believed that their way onto this vessel was to leave their human bodies. Over 39 members killed themselves over a three day period, believing the whole time that they were ascending to the “Next Level.”

I am very glad that I do not yet know anyone who is willing to die for their SDLC beliefs!

Though they may not die for it, you probably know a few people who will fight for it. I know people who have argued themselves hoarse and even quit jobs because of their beliefs in a specific SDLC.

There is a psychological reason why people hold so dearly to their chosen methodology. Having a methodology in place reduces the team’s or person’s responsibility when things go wrong. When something bad happens, it is human nature to want to blame something. It is easier to be the victim of the process, than the person responsible for the failure. Identifying a breakdown in process as a source for blame provides closure for past problems, gives a sense of present control, and often eases fear of future failure.

Let’s look at it from a different angle.

  • Has any SDLC claimed that it works perfectly every time no matter what?
  • Do you think any SDLC would grow and be recognized simply by name if it was prone to continuous failure?

I am not advocating No Methodology. After all, a failure to plan is surely a plan to fail. What I am suggesting is that you think of an SDLC as a tool, there are many different kinds and it is up to you to have the right ones available and which one to use for the job at hand.

Self-Directed, Self-Organized… Really?

One of the core ideas or principles of Agile teams is this notion of a self-directed, self-managed, and self-organized team. 

In my experience, it’s one of the hardest things to get right in your coaching and team evolution efforts. 

Often I see two extremes, either:

The teams use the self-organization, self-directed mantra as a means of having no accountability. It’s essentially the “inmates running the asylum” and they can choose to do whatever they wish, whenever they wish under the banner of – “don’t bother us…we’re being Agile”.

Or the other extreme is that:

The management team says that they’re empowering their self-directed teams, but when you look at their behavior, they’re doing what they’ve always done…tell folks what to do.

People also seem to like being told what to do; being micro-managed

Self-directed teams are teams that, once given a mission or goal, are expected to sort out the challenges and deliver. 

While this is a central notion, in my experience, it’s hard to get individuals and teams to take this on. I’m not quite sure why, because it’s really such a compelling premise. That is (You) own your own destiny (Results) so figure things out.

Instead of folks embracing it, I often see them fighting it. Is it a lack of practice in decision-making? Is it a fear of accountability? Is it a fear of failure? 

I’m not quite sure, but it could be aspects of all three and much more.

It seems that many of us have become comfortable complaining about things and “pointing upward” to “them” as being the problem. Point being, many individuals have become comfortable with being told what to do. With the accountability residing with their managers and they simply are – doing as they’re told. However, if Agile is done well, then “they” becomes “us”, which can be particularly scary.

On the flip side of this, when I do see individuals and teams embrace self-direction, then it’s a “magical” thing. There is a shared accountability between the leadership team and the teams doing the work. It’s balanced and effective, with each one supporting and trusting the other. 

But this balance can often be quite difficult to achieve.

{module ad 300×100 Large mobile}

What the Scrum Guide has to say…

Next let’s review what the Scrum Guide says related to the overall Scrum Team:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. 

And then it goes on to say the following about the Development Team:

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. 
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. 
Development Teams have the following characteristics: 

  • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
  • Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment; 
    • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule; 
    • Scrum recognizes no sub-teams in the Development Team, regardless of particular domains 
that need to be addressed like testing or business analysis; there are no exceptions to this 
rule; and, 
    • Individual Development Team members may have specialized skills and areas of focus, but 
accountability belongs to the Development Team as a whole. 

In this case the Scrum Guide is focusing the term self-organizing towards how the team decides to attack the work they’ve been asked to perform via the backlog. Schwaber and Sutherland seem to go to great lengths to emphasize the team owning and deciding work strategy. They also emphasize a blending of roles to the point where they are near meaningless. The key points seem to be: team, teamwork, delivery of a product increment and accountability.

What Esther Derby has to say…

In 2011, Esther Derby wrote a really nice article that tried to address some misconceptions related to self-directed teams. The three misconceptions she highlighted were:

1.Self-organizing teams are completely autonomous, self-managing, and don’t need managers.

2.All you need to do to form a self-organizing team is provide a goal and apply pressure.

3.Since the team is self-organizing, they can accommodate moving people on and off the team easily.

There is an overall misconception that Esther discusses surrounding the relationship, role or ‘dance’ between the self-organizing team and the leadership structure within the organization sometimes referred to as (‘management’). 

In most cases, there isn’t a whole lot of guidance coming from the Agile community around managing/leading agile teams. And usually what does come out emphasizes the team over management. What I mean by that is that management is basically told to “leave the team alone” or “go and handle a few impediments” as their primary role.

I really like the balanced (and necessary) role that Esther describes. 

Constraints? Or do the inmates indeed run the asylum?

There seem to be two schools of thought when it comes to applying constraints to Agile teams. One is that they’re inherently bad; that they undermine the empowerment and accountability of the teams. 

I sometimes see this in coaching colleagues who use terms like:

  • Agile Purism;
  • Un-Agile, Un-Lean;
  • Arbitrary or Dogmatic;
  • Prescriptive or Prescription.

To describe anything that “forces” the team to do something against their will. Literally they want the team to be unencumbered in their journey without literally any constraints. 

Unless you’re working in your own company, or for a non-profit perhaps, I’ve never encountered a job (yes, Agile team members usually work) with a total lack of constraints. Usually there are quite a few, for example:

  • quality constraints;
  • appropriate working conditions (language, dress, hours, etc.)
  • business & financial constraints;
  • agile constraints – Definition of Done, agile approaches used, tooling, etc.
  • legal constraints.

But at the same time as we’re applying constraints, we need to be careful that they’re not too oppressive – that they leave some room for the team to make their own rules and their own decisions.

Definition of Done

I’ll use Definition of Done as an example. I believe teams need to have a deep and broad definition of done. I wrote about what that means here and here. But at the same time, I usually encourage teams to “extend” their DoD with team-based agreements and to make it “their own”. 

I encourage the same thing to happen when the team is making other operational agreements amongst themselves. 

How do we “Create” these teams?

I don’t think you do. I think the leadership team has a responsibility to create a fertile space for these sorts of teams to form, become established, and grow. 

Aspects of which include:

  1. Staffing the team with the skills required to deliver on their backlog;
  2. Trying to avoid part-time team members at all costs; if you do have some, limit them and clearly define their “capacity” within the team;
  3. If you’re doing Scrum, have a dedicated Product Owner and Scrum Master. Make sure they have the experience, time, and focus to do the job well;
  4. Respect the autonomy of the team and trust them to deliver in your stated goals and directives;
  5. And engage in all aspects of the agile ceremonies so that you leverage the transparency and real-time adjustment nature of the methods.

And the team has self-direction responsibilities as well. For example:

  1. Holding each other accountable to professional ethics and standards;
  2. Having congruent discussions in retrospectives guiding the team towards continuous improvement;
  3. Having the courage to push back as appropriate on traditional leadership that might be pushing the team too hard or in the wrong direction;
  4. Holding quality dear within the team, not only from a Definition of Done perspective, but with solid professional attitudes and practices;
  5. An overall responsibility to respectfully work together (swarming around the work) and avoiding Scrummerfall behaviors – delivering as much high-quality and high-value software as possible.

Wrapping up

I’m quite curious as to how readers might react to this article. What are your experiences in achieving self-direction in your Agile adventures? Is it easy or hard? And have you seen team resistance to the notion?

Have you discovered anything worth sharing about how to achieve this level of organizational balance? I’d be very interested in hearing about it.

And is it something, that once you’ve achieved it, it sticks? Or do you have to continuously work on your self-direction, autonomy, and self-organization?

Stay agile my friends,


A few nice references

The Silver Bullet Syndrome

Over the past several years I have heard an increasing number of complaints from a large number of Agile adherents accusing organizational management of expecting Agile to be a silver bullet (usually stated as “the next silver bullet” although I am not sure what other “silver bullet” Agile is replacing).

These accusations usually occur when there are problems with Agile or the approach does not work as advertised and organizational management pulls the plug or reverts to more traditional software development or management approaches. These complaints are not unique to the Agile community, although they do seem to be somewhat IT related in general. Hearing them got me to thinking about the whole concept of the silver bullet, the results of which follow.

We in IT are fond of condemning management of organizations for continually looking for “The Silver Bullet”. There is certainly some evidence to support IT’s contention that management expects a “magical” solution to business problems. We can cite many instances of technologies or approaches in IT that rose to preeminence and then were cast aside as not having The One Answer:  Business Process Re-engineering comes to mind as an example.

Perhaps we feel we in IT have a greater insight into how things work since Fred Brooks paper was published back in 1986  titled “No Silver Bullet – Essence and Accidents of Software Engineering.” And to a large degree, technology, headed by computer technology, has been the victim of “the next great thing” for decades. Since we in IT are the ones producing “the next great thing” perhaps, like Pogo, “we are the Silver Bullet that we complain about”. [1]

The Evolution of the Silver Bullet

For those not aware of the legend of the silver bullet, in folklore a silver bullet fired from a gun is the only way to kill a werewolf. (Note that the silver bullet was also used by the fictional Western character, The Lone Ranger, as a calling card and a symbol of law and order. We are not referring to that particular use of silver bullet in IT.) Initially, in common parlance, a “silver bullet” referred to the only successful solution to a given problem or situation (to kill a werewolf for example). It was a positive concept. I can remember management meetings in which someone would say, “well, that looks like our silver bullet to resolve the issue.” And it was.

Since Brooks’ article, “silver bullet” has become a pejorative term usually applied to management with the emphasis on the fictional aspect of the concept: there are no werewolves, and, therefore, no “magic” silver bullets to kill them. In other words, there is no single approach or technology that will solve a complicated business problem.

Deus ex Machina

Perhaps we in IT might be better served by using the term Deus ex Machina rather than silver bullet. The Deus ex Machina, Greek for “god from the machine”, was a device used by playwrights, and others, to get the hero or protagonist out of an impossible situation by means of some unexpected, and marginally believable, power or event that occurs to save the day. Usually, in Greek plays it was portrayed as some god arriving in a chariot when things were darkest for the heroes (the monster was about to devour them, or the enemy wipe them out) to set things right and to save the day.

Deus ex Machina might be a better analogy for the single magical solution that management would like to see to solve its business problem: A new product, or technology, or approach that would get them out of whatever difficulty they are in, and most likely got into by their own actions, or lack thereof.

However, Deus ex Machina is hard to say and is not quite that familiar. After all, Greek drama is not a common course for MBAs, not to mention IT curricula. So it looks like we will have to live with the term “silver bullet”.

There is a Silver Bullet

The logical binary oriented computer and IT people declaim management’s persistent belief in and search for the silver bullet. IT people, especially in software development, and more especially in the Agile approaches, state categorically that there is no silver bullet. This may be a valid, logical conclusion, at least in IT, but it flies in the face of human nature.

We might recall as children getting ourselves into an untenable situation or simply being the victim of circumstances of which we could not get out. The situation seemed hopeless, at least to us. Then our parents or teachers or some other adult produced a solution to the problem, sometimes with money, sometimes with an action they took, and sometimes with some simple adult advice and counsel. Whatever was done, a single solution evaporated the unsolvable problem. And this is the way it is supposed to be. Children trip and fall and the adult gets rid of the pain and comforts the injured so the child can get up and run again. Children try something new that does not work in the adult steps and to make it right. In other words we are used to “silver bullets” even though as we look back as adults on those events, we realize they are simply adult solutions to problems that we as children could not determine. Still, as children filled with a sense of relief that the problem is solved, we would call them “Silver Bullets” if such a phrase were in our vocabulary.

Being so used to “adult intervention” is it any wonder that we humans believe in silver bullets?

Romance and Comedy

Hollywood contributes to our continuing belief in the silver bullet. In romantic movie after comedic movie, the lead character gets something (love of their life, money, etc.), the lead character loses it, and then by some magical happenstance, the lead character gets it back (usually along with some insights) in the third act, and everyone lives happily ever after. Centuries of books, plays, operas, and nearly a century of movies (not to mention television and now Internet shows) have conditioned us to expect some kind of silver bullet to make everything right by the final credits. Regardless of how implausible, Andy Hardy puts on a show to save the orphanage. Cars line up for miles waiting to pay money to visit the Field of Dreams and save the farm from foreclosure. King Richard returns just in time to save Robin Hood from the forces of King John. The real criminal confesses to save the innocent man’s execution just before midnight. And so forth.

Our popular culture continues to reinforce the belief that somehow, someone or something will come along and save the day. More silver bullets.

The 24 Effect

In the very popular television series 24, the lead character, Jack Bauer, played by Kiefer Sutherland, had two often repeated phrases. The first, “dammit”, spawned a college drinking game. The second phrase, repeated in nearly every episode, shows how ingrained the concept of the silver bullet is in our culture. The phrase is “this is the only way”, usually stated after another character recites a laundry list of risks, such as death to Mr. Bauer.  Not only is Jack Bauer stating a single solution that will magically solve the problem (the problem of that 15-minute segment anyway) but the solution generally, in fact, works. And we believe it, or at least we suspend our disbelief.

As humans, we want to believe that there is a solution, even a “magical” solution that will get us out of our most dire situations.

This is called hope. And hope is not a bad thing.

And who knows? Maybe there are silver bullets. After all, someone has to win the lottery.

Silver Bullet Expectations

There are two primary reasons that Business Analysts have to be aware of the natural occurrence of the belief in silver bullets. We might call this the “Silver Bullet Bias.”

The first is one of expectations. This is the primary reason behind the negative connotation to the phrase “silver bullet”. If management assumes that a solution, for example an Agile approach, is a silver bullet, management will assume that the problem will be completely solved with no other action necessary.

Part of the reason for the Silver Bullet Bias is those who are proponents of the approach, the zealots or true believers.  There has been a lot of hype about Agile, for example, especially from the Agile advocates themselves. Agile, a software development philosophy or mindset, has been pushed to the corporate level far removed from the developers who signed the Agile Manifesto with promises that if the organization is Agile, great things will happen in software development and elsewhere (sales, marketing, customer service, etc.)  There is no mention of the work necessary and one of the underlying principles of Agile, which is that failure is necessary for success. Based on the concept that management is made up of human beings (although there are those in IT who doubt that concept), management will naturally jump at the possibility of a silver bullet.  We have only ourselves to blame for their expectations.

Expectations can be managed. Identifying the risks involved with the proposed solution, the shortcomings of the solution, and the aspects of the problem that may not be solved by this “silver bullet” solution will put the “silver bullet” in its proper context. Sometimes placing a potential solution in a realistic scenario including risks, impacts and limitations might force management to look for other solutions, which is never a bad thing, time permitting, and in many cases, the constraints of time tend to be artificial.

No Other Way

The second issue is more insidious. If management or anyone assumes a silver bullet approach, they will not consider any other options, and have a tendency to overlook the risks, similar to the 24 effect. If the solution is the “only way”, then there is no need to do risk analysis for the purpose of determining the alternative with the least risk, much less come up with another alternative. And this can be disastrous. 

The last thing a Business Analyst wants to hear about a failed solution is “we didn’t consider…” I’m not talking hindsight bias where the phrase is “If only we had known this would happen”.  I’m suggesting that additional information or analysis was stopped, prevented, because a silver bullet appeared and became “the only way.”  As Courtney Turk says in The Secret Diary of Ashley Juergens, or as Dr. Mouhamed Tarazi titles his book:  “There is always another way.” Or as Sherlock Holmes would say, “It’s a capital crime to theorize before you have all the evidence. It biases the judgment.”

The silver bullet is sometimes another way of jumping to solutions, or worse, ignoring or discounting any other possible solution (confirmation bias).

“No Silver Bullet” is a Silver Bullet

And, finally, the Silver Bullet Bias can be used as an excuse. It’s easy to say management is wrong because they want a silver bullet, and expect every solution to be a silver bullet and that’s why didn’t work. 

“Management expected Agile to be a silver bullet, so they pulled the plug on it when it didn’t solve all their problems.”  This is a convenient excuse, and it may hide the real reasons for the failure. Perhaps expectations were not set at the right level. Perhaps the approach was not correctly implemented. Perhaps the implementers tried to shoehorn the organization into a standard approach when customization, while more difficult, was called for. It’s easy to blame things that don’t go your way in business as a negative attitude on the part of management. The harder thing to do is to evaluate and assess and come back with a plan to do it right the next time (or at least to do it “righter”).

What can the Business Analyst do about it?

We recognize that all of us want, and to a degree believe in a silver bullet, to rescue us from whatever difficulties we are in.  While we cannot eliminate silver bullet thinking, we can address the issues of Silver Bullet Bias in business.

Considering the aspect of the “one and only” solution, the Business Analyst will offer multiple solutions to any business problem – or for that matter, any problem at all. The solutions do not have to be mutually exclusive nor realistic. In other words, one solution might be too expensive, and another realistic but improbable.  Solutions might be variations on the same theme. But they will be separately identifiable solutions to the problem.  Faced with options to solve the problem, management will likely recognize that the Silver Bullet solution is not the only way to go, and be forced into evaluating alternatives to come up with the best viable approach.

The Business Analyst can throw a little tarnish on the silver bullet showing that the solution may not provide all the answers or relief. The Business Analyst provides measurements and metrics pinpointing where the solution may fall short, and how management can determine that the solution is viable (or not). In this way, the “magic” of the silver bullet solution starts being replaced by situational reality. Management can begin to see behind the curtain.  Remember that even when the magic of the Wizard of Oz was shown to be fraud, the Wizard still satisfied everyone’s goals for going to Oz: a heart for the Tin Woodman, brain for the Scarecrow, courage for the Lion, and Kansas for Dorothy. The reality is that goals and solutions can be achieved without the silver bullet.

And, who knows, maybe the Business Analyst will show that the solution was, in fact, a silver bullet.

[1] The comic strip, “Pogo”, scripted by the late Walt Kelly (1913 – 1973) produced many quotes, among which, the most famous is “We have met the enemy, and he is us.”

6 Useful Mobile Analytics Apps to Gain Business Intelligence

The focus of the business world has shifted from personal computers to Smartphones. Most e-commerce businesses are now offering their mobile applications,

whereas some businesses are solely operating through mobile applications. With a staggering 6 billion Smartphone users anticipated in 2018, the m-commerce industry has a huge market for expansion. Analytics using mobile apps has become important in the Smartphone dominated market. Following are some smart business intelligence apps that can help in gaining deep business insights for better analytics.

1. RoamBI (Available for iOS, Android, Windows 8 Tablets & PC)

This application has any good spreadsheet analyzing capabilities. It can take data from various sources which includes SAP business objects, IBM Cognos, OBIEE, Microsoft reporting and Analysis services as well as Excel, Google Docs, Salesforce and more and present the data on iPad or iPhone. Roambi Pro is a hosted service for SMB’s and workgroups that creates a visualization from Excel, Google Spreadsheets, and Salesforce CRM. This application doesn’t have its own backend; it can only present data generated by other BI software.

2. QlikView on Mobile(Available for iOS, Android)

This is one of the most powerful tools for gaining business intelligence as it facilitates the creation and consumption of dynamic applications for analyzing information. QlikView provides fully interactive applications through HTML5. The app is available for iOS and android platform. It has an in-memory dynamic calculation engine which requires a server connection for real time analysis. It also has the ability to download and bookmark views for iOS which can be accessed in offline mode as well.

3. Renew Analytics application (Available for Android)

Renew Analytics app provided by Service Source has good data analysis capabilities. This app is very useful for recurring revenue business as it can track key performance drivers. It also provides role based access to key real time data sources. It provides a powerful dashboard for analysis of historical metrics and forecast.

Related Article: 10 Essential Apps for the Business Analyst

4. SalesClic (Available on Google Apps Marketplace)

If you want to have a better sales management through a mobile app, then SalesClic will be of great utility. It can easily integrate with Google Apps, Highrise, and Salesforce. It helps in fine tuning sales process by utilizing the historical data which are stored in Salesforce or any other database. It also helps in identifying opportunities and minimizing risk. It also helps in improving sales forecast.

5. Birst Mobile (Available for iOS, Android, Windows 8 Tablets & PC)

It is Software-as-a-service (Saas) business intelligence solution feature that includes an integrated ETL (extract, transform, load), data warehouse automation, enterprise reporting, ad hoc querying and dashboard. The app doesn’t require separate dashboards for different devices; a single iPad can be used to access all dashboards. The added advantage of using this application is that it takes leverage of iPad touch screen interface to swipe down, to scroll through rows in a table and use the two-fingers-spread to zoom in.

6. Yellow Fin(Available for iPad)

For combining multiple data sources and querying of multiple different databases to create a single report or dashboard, Yellow Fin is a handy mobile app. The advantage of using this app on mobile is that it renders a similar view as it delivers on desktop screen. The app is available in the online as well as offline mode.

Don’t Force Typical Templates on Packaged Software Projects

One of the most interesting trends I’ve seen in my business analysis career is the shift from custom software development to package software implementation.

Traditionally, large corporations created in-house teams that supported business functions by developing software from scratch. Gradually, package software made its way onto desktops via word processors and spreadsheets. Then, package software began to take over organizational support functions like human resources, payroll, accounting, and niche functionality. Now, highly configurable cloud packages provide or supplement even core business functions in most companies; ranging from small functional packages to large enterprise software.

The context and scope of package software projects vary widely. Common package software projects include one or more of the following:

  • Upgrade: technical and/or functional
  • New implementation: out of the box, configuration, and/or customizing
  • Integration with other systems (in-house or vendor supported).

As packaged, third-party solutions become more common, BAs need to modify their traditional approach to meet the unique needs of package software projects.

I first started outlining these differences in my team practices and on my projects back in the late 90s. Since that time, I’ve seen a huge jump in the complexity of these implementations. While requirements analysis and implementation analysis for package software have not changed much, the risk of getting it wrong has increased dramatically.

The mindset that needs to change, not the techniques

The BA role remains the same for traditional projects and package software projects: protect and optimize stakeholder and organizational value. Many of the same techniques can be used, but the BA mindset and how it’s all documented and facilitated may change.

Worry about fit, gaps and change management

When working on package software projects, a fit/gap analysis mindset is crucial along with a keen focus on how the users world is changing and empathy for these changes.
BAs need to look at how the package “fits” the desired outcomes and processes, and identify gaps between the package functions and the current state functions. BAs should work with stakeholders to determine if gaps need to be “bridged”—can we operate within the package functions or do we need to adapt the process or technology to meet our needs?

WickJuly14 2

Documenting this fit/gap decision process is a key BA role, including facilitating options and alternatives to minimize the gaps. Even when implementing “out of box,” this process and analysis is critical to success. “Out of the box” typically means process or operational changes somewhere, BAs are in the role to identify where the changes will happen and prepare the users for these changes.

Don’t force the templates

Once BAs enter the fit/gap mindset, then they need to determine how to effectively document the package software project.

I often see BA teams struggle as they hold on tightly to their templates, trying to make them work for package software projects. Many typical templates don’t serve package software projects well. Typical templates assume a custom development approach, and forcing BAs to use these templates creates a lot of pain and challenges for package software projects.

So PLEASE, challenge traditional practices and templates when participating in package software projects. You still need requirements, but timing, and level of detail/abstraction must be appropriate.

Careful not to waste time on detailed documentation of your organization’s current state. The vendor usually has current state documentation for the package and this will become the future state in most cases. Focus on the future state and what must happen going forward, only looking back to the detailed current state when we need to identify details to carry forward. Also, it’s likely project sponsors purchased the package to gain efficiencies and change processes and business operation—they don’t want an exact replica of current state.

Instead, manage your work at a function level. Before selecting the package, what an actor wants to accomplish and rules are important. After selecting the package, the future state and “how” the actor accomplishes it becomes important as a change management piece for piloting, testing, training, and implementation.

We don’t want to document functionality already built. Exactly how it’s done in the package can be redundant to document when the vendor typically has this documented. So, avoid documenting requirements for package software that duplicates functional specs and design of software already built.

Don’t rely on the vendors BA 100% for the BA role

WickJuly14 3You need an internal BA (or BA team) to support a package software project. If you rely solely on the vendor BA, you will not successfully identify and bridge functionality gaps. The vendor BA understands the product, but does not fully understand your environment—your systems, processes, culture, politics, pain points, exception processing, integration issues, etc.

Both BAs—vendor and internal—are critical to success. The internal BA does not fully understand the product and needs the vendor BA to validate functionality and fill gaps.

Whether it’s two people or two hundred, the internal and vendor teams need to come together like puzzle to teach each other, build trust, and work through issues.

Upgrades need BAs

It’s quite common to hear teams say that package software upgrades don’t need BAs or requirements.

Challenge this assumption! Upgrades almost always have user impact or at least a risk of user impact. If users use the system, there are requirements!

Whether the change is minor or technical, a knowledgeable BA should be consulted. Even if the upgrade has been successful at several other sites, there is still a chance that your organization’s unique configuration or system integration could be negatively affected by the upgrade.

So ask requirement-resistant team members a few questions like: Why are we spending money on the upgrade? How do the users benefit? What would happen if it’s not done? Help them understand potential impacts and how BAs bring value to all projects.

WickJuly14 4A note about configuration

Most modern package software is highly configurable with hundreds of settings that impact software functionality.

If your project team has not worked with highly configurable software before, be prepared for a new layer of complexity throughout the project lifecycle.

  • BAs may need to consider configuration settings when writing business rules or detailed requirements.
  • Projects may require a separate phase of “configuration testing” and piloting the package.
  • BAs may need to educate testers about configuration settings and help them trouble shoot issues/bugs to determine if the errors are configuration errors or system bugs.

BAs will be supporting even more package software implementations in the future. If you haven’t experienced a package software project yet, you will soon—be ready.

Don’t forget to leave your comments below.

Doodle images above provided by Dan Wagner. Learn more about Dan’s doodle art by emailing him at [email protected]