In Bulfinch’s Mythology he states that after nine years of military failures to take Troy, the Greek armies were despondent and “resolved to resort to stratagem.” I’ve been on that project! We as business analysts are like Odysseus, coming up with ideas to try to get behind that great walled city and celebrate victory. The project manager for the Trojan War was Agamemnon, focused on the goal of victory but without a sense of how to do it. Surrounding him were his project team: all the armies of Greece, a thousand ships worth, all with different voices and different agendas. We remember the Greek armies as victorious. We remember the Trojan Horse as the final bit of cunning that won the war. But as business analysts we cannot fight a war for nine years. Users, stakeholders, management don’t remember the result, only the amount of pain that it takes us to complete a project. When we have a huge undertaking like the conquest of Troy, special tools can be used to make our success more likely. In this piece, we will focus on three tools that we as Odysseus can use to make the project better. In Part II we will look at ways to help Agamemnon strategize.

A “Cross-platform Initiative” for the purposes of this article is a term that will be used for a project in which multiple groups are involved, and bring to the table their own iteration of the same business roles. For example, on a project within a group there may be some analysts, a lead analyst, a project manager, some subject matter experts, stakeholders and perhaps others. But in the cross-platform project, two, five, ten, maybe twenty groups bring their own lead analysts, project managers, and stakeholders to the table. Frequently these projects start at the behest of one group, and the rest work on a common solution to deliver a new product, process, or set of tools. When the groups come together there is an implicit assumption that they can work within their own silo to determine schedules, business requirements, and developmental goals and easily compile their products at the end. This assumption is almost always wrong. Business analysts can use tools upfront to ensure that groups work in concert and produce output together. These tools probably aren’t news to anyone, but are techniques that one often skips when working on a smaller project with limited risk. On a big project, that risk exponentially increases based on the number of groups involved.

Creating a Requirements Plan and Sizing
On a small initiative, the project manager asks, “how long will it take for requirements” or maybe even asks, “can you do requirements in two weeks?” The business analyst looks at other commitments, considers how long it will take and says, “yes, I can get it done in that time.” The business analyst makes assumptions based on familiarity with the group, previous project experiences, and their own work ethic. The business analyst keeps getting put on bigger and more important projects because they do thorough work and usually meet their deadlines. Then a cross-platform initiative begins. In the first overall project meeting, the project manager asks each group if they can make a deadline in creation of “their group’s requirements.” Each analyst is in the position of estimating time internally again. If the estimates are right 80% of the time and we have twenty groups on a project, at least four aren’t going to meet the deadline. Also, an assumption has been made that the requirements can be done in isolation and will fit together seamlessly at the end. If that assumption is wrong (which it will be unless we have the most modular system ever), we find gaps in our requirements during review after the deadline, and the time spent between groups to resolve those gaps is holding up proposed development dates.

We can’t hold project managers accountable for wanting to set schedules in a way that seems arbitrary, they just don’t know what we will have to do during requirements gathering. When asked about a deadline on a new project, instead say, “let’s not set a schedule today, we’ll get back to you in a week.” Business analysts and subject matter experts from each participant group can get together and determine what kind of requirements and effort they will need. Each group sits down for an hour or a day and hammers out every system, process, piece of code, or interface that needs to be changed. Then the analysts from each group get together and compare notes. Any item that appears on more than one group’s list is a topic for a cross-platform requirements gathering session. The analysts can then determine requirements gathering time within their group and for each conversation they need to have externally. Those few days of analysis up front can create a reasonable timeline which can be communicated to the project manager: groups A, B, and D can be done in two weeks, and group C and E will need at least five weeks to complete several mapping exercises. Real expectations have been communicated and the project manager can make a plan instead of just setting a schedule. The group may not want to wait a couple days or a week for the initial analysis and sizing. The project manager will not be comfortable and will say that a schedule is needed. But analysts should not be bullied into agreeing to an arbitrary completion date if a little bit of work can produce a goal which can actually be achieved. Management prefers project groups that reach their own goals over groups that promise soon and deliver later.

Identify and Walk Through Special Cases
Groups should have a test deck of special cases for their systems and processes. Most large enterprises have such unique cases: after a merger there are two types of customer identifiers, mortgage records are different in New York, the Japanese Yen has no decimal places, platinum customers don’t have to go through certain process steps, products with saccharin require a warning label, etc. During requirement reviews for large initiatives, prior to development, take the time to go through each group’s special cases with the subject matter experts from all the other groups. Have enough subject matter experts on the line to truly evaluate whether or not a special case will create a challenge to a system. These are challenges that we don’t want to find once we get to testing because they could mean changes to data structures or process flows. They could take a long time to repair, or our end product may be incomplete.

One time while working on a financial systems project, I was working with a source system which would automatically append “.00” to an amount if the user did not key in “cents.” We were unaware of that, and did not review our special cases before development. In early testing we processed a transaction through in Japanese Yen. Their system appended “.00” to the amount, it passed through many intermediate systems, and then failed once it came to my group because Japanese Yen don’t have an equivalent for “cents.” Crisis! My group is required to perform the validation, so we can’t remove it from our code. The sending application would need to change data definitions and input screens to avoid the error in the future. What will happen with the intermediate applications? If we had gone through our special cases up front, we would have known that the sending application appends cents, and they would have known we couldn’t accept cents in all cases. Our coding could be proactive instead of reactive, and we could resolve the issue in design and development instead of emergency fixes during testing.

Don’t Just Hope for the Best: Proofs of Concept for Data Movement
Every large scale project I’ve worked on has had an “ah-hah moment” in testing related to data transmission, not because we didn’t do the analytical work up front, but because we showed a requirements document to someone who said, “yes, I think that will work” and was wrong. In a small project, we are only dealing with one or two systems and can quickly resolve problems found in testing, even serious process gaps. But when speaking of twenty systems, the effort to resolve issues in testing might be huge or might not even be able to be done! Proof of concept files or deliveries can avoid some of these headaches.

Opportunities to stage a proof of concept occur when the group finds themselves making an assumption about the workings of the current system or process in relation to the future system or process. Rather than waiting for coding on all systems to be complete, we pass what we can through systems manually. Sometimes this involves sending files by hand across platforms into downstream applications. I have received resistance to this practice when testing resources in other groups didn’t want to load manually generated data. But we can save a lot of time if we make sure our plan works (prove our concept) before we code it.

On a recent project, my group created a mapping of many fields of data into a new system we were getting from an external vendor. We made certain assumptions about the new system from vendor diagrams, schematics, and conversations, but really could we be sure that our data was going to work? We received the new system, but our development team had not completed the sending application’s changes. Rather than waiting to determine if our mapping exercise was going to work, we mocked up files the way we expected them to be produced and loaded them into the new system. Indeed, some of our assumptions about the destination data structures were wrong. Automatic validations within the vendor system would reject most of our data. Because our internal development was still in progress, we were able to redirect those efforts and rather than wasting a lot of development time, we only wasted a little, and the cost was a couple hours of analysis.

Analysts can use proof of concept test for any change that might create gaps. Using a new alpha numeric customer reference and need to see if it’s going to break any downstream applications? Don’t just rely on old system diagrams, e-mails, and wait for testing to start. Do it yourself and save.

Not Another Troy
A nine year project is unacceptable. And a project with shifting goals, strategies, schedules, and so on will also be unacceptable to the stakeholders involved. By using analytical tools upfront we can prevent those “ah-hah” moments from making us change course or alter our designs mid-project, and we can overcome the increased risks associated with cross-platform initiatives.