It’s the End of the Business Analysis World as We Know It

Where Does the Business Analyst Go From Here?

Being the serialized story of Brian Allen and Ann Brady, business analysts, and their Adventures in the New Oder of Agile

Chapter 1 How it began

Now he was concerned. Brian had weathered pretty much everything the organization could throw at a business analyst from the early days when he had to fight just to make the role a viable position in the organization to the past few years when he was under constant pressure to take over project management jobs in addition to his business analyst work. Brian was flattered that they felt that he had the capability to do both jobs simultaneously, but his heart was in business analysis and he was afraid that if he diluted his efforts by also managing he would seriously impair the enterprise level project he was on. Besides he had already done the project management thing. It was interesting and challenging, but it wasn’t what he wanted. 

Now things were changing once again. The project he was on was a long term, several year reconstruction of one of the primary internal systems. It was one of the first systems the company had built to provide internal control over sales, marketing, order processing and just about everything associated with the organization’s backbone. The system was the pride and joy of the CIO, Carl, who was on the team that developed the system twenty years ago and it took some convincing, and a bit of arm turning, for the CIO to finally admit that the system needed an overhaul. Since he identified so closely with the system, it was as though he himself needed an overhaul. As a result, Carl also looked at the way the organization had been developing software over the years and despite a highly successful record of on-time delivery, at least on the internal mainframe based systems, the CIO decided that perhaps the organization should segue into agile. 

The web site maintenance had converted to an agile approach to software development a few years back and been successful after some bumps. There were some teams here and there on the periphery of the internal systems that were run with an agile approach, mostly in maintenance activities. But the primary systems, based on the trusty IBM computers and written in Good Old COBOL, with a smattering of Assembler Language Code, were still maintained in a structured software development approach patterned after the linear, waterfall, model. Major new efforts, like the overhaul of the purchase order system which took two years was also done the traditional way.

Since the entire backbone system of the organization was going to be rewritten – code, databases, architecture, even some new networks – Carl had decided that everything might as well get more “modern’ as well. They were even relocating various offices and departments. 

So Brian was worried. He and Ann were the lead business analysts in the organization and from his understanding of agile and its mystiques; he was looking at the end of his career as a business analyst in the organization. Neither he nor Ann wanted to leave. Their roots ran deep in the organization. But Ken, the leading Scrum advocate, who had led successful Scrum teams and Theresa, the technical lead, who was a staunch Extreme Programming (XP) advocate, were both onboard with the software development conversion and had advised Brian and Ann independently that the services of the business analyst were no longer required in the New World. 

It wasn’t pretty. Brian still shuddered when remembering the show down meeting when the CIO decided to give the green light to the New Order of Development. What was ironic was that Brian had been a vocal proponent of the overhaul of the old system and was instrumental in influencing the CIO and executive committee to launch the new program that appeared to signal the death of his own job. Brian in fact, with Ann’s help, had written the successful business case! 

Brian, of course, protested loudly in front of Carl, Vince, the Vice President of Marketing and heir apparent to the CEO’s job, and Olivia the Vice President of Operations, asking how the teams were going to determine what they had to do for the new system.

“Do any of your programmers have experience with inventory turns or balancing a cash receipts journal?” Brian had taken accounting courses and even a CPA overview from the state CPA association to keep up to date on accounting. 

“They don’t have to be experts,” Ken countered. “We have the experts in the business who can tell the developers (he emphasized the word to remind Brian how out of touch he had become) what needs to be done. It’s not a problem. It’s time the developers and the business cut out the middle man, er, person (acknowledging Ann) and let the solution meet the problem directly.”

Ann spoke up. ”I’ve spent years with both the developers and business people. I don’t think the developers care to sit in long meetings and discuss the intricacies and ambiguities of supply chains and customer service. They have always preferred to just get the facts: what they have to do to solve the problem.”

Ken responded before Ann could finish. “This is the New Order, Ann. The developers are going to get with it and learn about the business. They are going to learn negotiation and interaction. Things are changing. We’re taking the developers out of their development hovels and moving them across the aisle.”

“Even if they don’t want to go? Even if they prefer just to code?” Brian asked remembering the days when he started out as a programmer and worked with many peers who really didn’t want to talk to anyone in the business. 

“Yes,” replied Ken. “That is the Way of Agile.” He said it with a slight reverence as though talking about an Eastern Philosophy like Zen. Brian thought he saw Ken put his hands in front of his stomach and bow slightly with a Yin and Yang symbol hovering over his head. 

Ann recovered the floor. “And I have not seen many of the business people who will jump at the chance to spend all their time with the developers and sacrifice their daily jobs. They don’t understand how the developers need to hear the specifications. They don’t understand how to specify requirements.”

Ken, in his enthusiasm, jumped in again, “They don’t specify requirements. Requirements are dead.” Brian thought he heard an underlying meaning in that statement: “Business analysts are dead along with the requirements.” 

Ken explained, “We use user stories now. We don’t do requirements. Not only are requirements inefficient, tedious, generally unworkable, and unreliable, they are also boring. User stories are easy enough even users can do them. And we are also making the whole burdensome change management system that has infiltrated everything in our culture obsolete. No more green and pink forms, no cumbersome on line system that people forget to update, no endless change management meetings with the CCB that doesn’t want to be there in the first place, no politics,” Ken’s voice was raising, sounding like a politician in front of a Labor Day political rally crowd. “There will be no more risk management exercises with a Risk Register maintained by a Project Administrator, no Earned Value graphs and charts and reports, and, consider this, sir,” he said addressing Vince, “no more project managers or PMO.” 

Ken, and everyone on the table, knew that the PMO and to a large degree the whole project management structure of the organization had been a thorn in Vince’s side for years. Vince hated the paperwork and time consuming processes that the PMO had established to provide some semblance of control and prioritizing of the projects in the organization. Vince was known to protest loudly to anyone who would listen, especially his golfing buddy, Charles Evans, the CEO, “We’re losing ground to the new and faster and more agile competitors out there. They get to market much faster than we do. They have a more agile approach to product development. When we come in with a change, it’s either in response to a competitor’s move or to market demand. If we don’t act fast we lose market share (market share was an important issue to Charles). If I have to go through all this paperwork and committee approval and business analysis and requirements and stuff…it takes longer to get something approved than to just get it done!” And unfortunately, Brian knew that was true to a large degree, but he was also around in the old days when everyone in Management Information Systems (MIS), as it was called then, seemed to be working on the demand du jour with no order or priority or sense. Efforts were introduced and dropped, replaced by other initiatives from executives with higher political clout, or urgency, and then brought back out of their hiatus with the admonition that they should already have been done. It was chaos. Projects failed not because they were mismanaged but because of the conflicting priorities and the disorder in the assignment of resources and the frenetic communications channels. Everyone in the organization could talk to any programmer at any time to get anything done. Brian was somewhat proud of the work he and Ann had done in bringing order to the business process of managing organizational change. He never took Vince’s complaints too seriously because the system was working fine for the rest of the organization. 

It was then that Brian realized that Ken was in cahoots with Vince and had Vince’s complete support for the New Order. And Vince, as the next CEO, had the political clout. It looked like the Organizational Change Management system that had run successfully for these many years was as doomed as well. 

“And as for the business people, they will love being able to get their needs met immediately in the order that they want them met. They will be able to change their mind, change their needs, change their approach, try new things and then try something else without the imprimatur of fighting the system to get things done. We see a major increase in innovation because the barriers to creative failure will be removed.”

Brian wondered where Ken had picked up the phrase “creative failure”. He knew it won points with Vince. 

Brian and Ann fought to hold down their frustration. They lodged all the objections they could muster, but to no avail. The New Order was coming to the Organization. And that meant that there was no place in the New Order of Things for either of them or any of their cohorts on the Business Analyst Team that he and Ann had struggled so long to set up. 

Brian’s thought, unexpressed to Ann who was lost in her own downtrodden thoughts, was “I’m way too young to retire, and way too old to start over again in a different organization or a different career. Besides, I really, really, really love being a business analyst.” 

Brian was now being summoned into Pauline’s office. Pauline was the head of the PMO to which the Business Analyst Team reported. As he walked down the corridor which seemed a lot longer this morning than ever before, feeling like he was walking to his own execution, he was wondering, “what happens now? Is there no place for a business analyst in the New Order of Agile?”

With a shudder, Brian gathered himself together and opened the door to Pauline’s office.

“Ah, Brian,” said Pauline, not really smiling. “We have to talk. I’ll be talking to Ann next.”

What is going to happen to Brian facing the Perils of Pauline? Will the Business Analysis Team and the Change Management System survive? What about Ann and the rest of the business analysts in the organization? Join Brian, Ann and the rest of the Business Analyst Team in the next episode of Brian and Ann and the New Order of Agile next month.

Don’t forget to leave your comments below.

Excerpted from the forthcoming book from John Wiley, The Agile Business Analyst due out the end of 2013