Do you know your Modernization Project requirements?

Updated: Jan 18, 2023

You guys start coding, I’ll go find out what they want

You undoubtedly have seen the broadly circulated cartoon with this punch line. It’s funny because for many of us it comes too close to reality of many projects that are done with very poorly defined requirements. You have also probably seen the famous “Tree Swing” cartoon of requirements drift that has floated around for years. In this cartoon, a collection of improbable variations on a simple tree swing diverge further and further from the client’s desire for an old car tire tied by a rope to a sturdy tree branch. Here are two of my favorite panels from “Tree Swing.”

Does it have to be this way? Let’s find out. The usual way that requirements are documented begins in a requirements meeting, often the first of so many.

Meetings, meetings, and more meetings…

How productive are these so-called requirement meetings? Ever attend a requirements gathering meeting that turned into a “verbal” food fight, al la Animal House? How about a meeting with no agenda, where attendees checked email while the boss rambled on, the unquestioned answers far outnumbered unanswered questions, and no “action list” appeared for post-meeting follow-up? There is a better way to have a meeting of the minds with your colleagues and stakeholders. The better way is a “workshop.”

Why a workshop?

Why is a workshop a better way? Because it is guided by a facilitator whose mission it is to ensure the workshop team jells, and produces the results it is capable of producing.

Facilitation… What’s that?

According to Don Paulson of Iowa State University, facilitation is “the art of leading people through processes towards agreed-upon objectives in a manner that encourages participation, ownership and creativity from all involved”. That sounds great, but what does it really mean?

It means commitment from the facilitator and the participants. They must rapidly traverse the team dynamics arc proposed by Bruce Tuckman (Tuckman, 1965), as Forming, Storming, Norming, and Performing.

The facilitator guides, advises, and mentors the team to:

Appreciate the ground rules of the workshop and the workshop goals (Forming),
Conquer startup hurdles, interpersonal issues, and believe the workshop can achieve its goals (Storming)
Recognize and accept the contributions and interaction styles of their fellow participants (Norming), and
Create the workshop deliverables together, according to the workshop’s goals (Performing)

So the Workshop Facilitator eases the team’s travel through the team dynamics arc to attain workshop goals. What goals might those be? Naturally, it depends…

Workshop goals

If you are modernizing legacy applications, an early requirement is to decide what should be modernized. Some evaluation of your legacy application portfolio must take place. You will need to decide which application suites will provide the greatest benefit and/or cost relief from modernization. The process of evaluating the costs vs. benefits of your application portfolio is called “Application Rationalization”. The “application facts” should be gathered and assembled impartially, but the results will need discussion and a meeting of the minds. Invariably, application suites have their champions, and a facilitated workshop is an excellent vehicle for the horse-trading and sausage-making that will go on. In this case, the workshop goal is to prepare a modernization project charter, and prioritized list of application suites for modernization.

Once the hard choices have been made about which application suite will be modernized first, additional workshops should be scheduled to cover, for example, modernization resource planning and scheduling, issues and problems with the present system, and desired future enhancements. Each workshop’s goals will result in deliverables providing validated input to future project stages.

If you are developing new software solutions then instead of prioritizing application suites, workshops will have a different focus. Solution requirements, glossaries that ensure a common understanding of terms across stakeholder groups, business policies and their impact on business rules, and similar critical elements will require discussion and analysis. Using TIC’s Model-Driven Architecture (MDA) approach, some workshops will be review and discussion sessions where models are reviewed, revised, and approved. So, new software development workshop goals would include producing relevant deliverables, and also include identifying areas of disagreement where workshop negotiation is not sufficient to gain consensus.

Situations will arise in which consensus will not be found in the workshop. The workshop facilitator is not an arbitrator who “makes the call” when the workshop participants cannot agree. Sometimes disagreement is a good thing, indicating a greater degree of attention must be paid to the area of disagreement. Facts in dispute, lack of clarity about business concerns and policies, and governance and “territorial tensions” will all lead to additional efforts outside the workshop, or demand guidance from higher organizational powers.

Who’s got time for this? Let’s start coding!

You may think all of this workshop “stuff” is a huge commitment of time and effort, but a workshop is really a big time saver. Imagine what would happen if your organization embarked on a legacy modernization effort with no consensus on what to do first, who is to be responsible for what, which resources will be need and when, and similar issues critical to success. That approach would really consume time and money, but it would not produce good results.

TIC Workshops

Our workshops are facilitated meetings attended by at least two TIC professionals and up to 10 participants from our client’s team. Before TIC arrives on the scene we’ve ensured there is agreement on workshop scope and agenda. Once the workshop begins we keep things moving in a friendly and orderly way. In other words, no food fights and no “checked out” attendees… but running a facilitated meeting is much more than ticking milestones off the agenda while keeping participants awake or from coming to blows.

Facilitation is an important “soft” skill set that might be underappreciated in a technically focused world. The “stuff “of facilitation is helping the workshop to succeed. We do this by guiding the workshop process, and ensuring that group members communicate clearly, maintain focus on problem solving, and keep conflict to an acceptable level. When decisions are taken, or questions arise, we track them, ensuring that decisions receive action, and questions receive answers.

NonStop, MDA, and Workshops

TIC Software using the MDA tool suite from our business partner BluAge and a workshop approach to consensus-building, is helping customers build NonStop Java applications quickly. However, there is some thinking to do before generating code. Workshops will bring clarity to your stakeholders. Here are some good workshop applications.

Selecting a TIC Quick Start Candidate Application
Use a workshop to build consensus, and agree on what to modernize or develop
Assessing the results of a TIC Quick Start Workshops are excellent for assembling lessons learned, before a full-scale effort begins.
Building a business case for modernization A workshop is an excellent venue to discuss, analyze, and agree on the direct and collateral impacts that modernization will bring.
Planning software development iterations A workshop is a great vehicle for iteration review and planning.

Take Away

Workshops give you and your organization the edge it needs to ensure modernization or new development yields solid results, on time, and in budget. Our workshop approach focuses on bringing you success, whether you are:

Deciding what to modernize
Planning a new software development project.

Once the hard choices of what to modernize, or what to build have been made, workshops continue to deliver value. Our MDA approach is based on building models, and generating software solutions. Workshops enable business stakeholders and technical staff to participate, together, in the modeling process. Modeling workshops focus on critical elements like business rules, calculations, and process flows, while code generation handles “application burden” with frameworks.

Whether you are interested in brand-new development, or want to re-engineer your existing COBOL applications into Java, TIC, and our modeling with BluAge will make things happen more quickly, with higher quality, and lower solution life cycle cost.

Are you ready to learn more about TIC, modeling with BluAge, and what it means for your NonStop environment? Schedule a conversation by emailing us at sales-support@ticsoftware.com

Feedback please

Do you find this tutorial blog helpful? Let us know what you think, and how we can make it even better. Don’t forget, you can subscribe to our blogs to get automatic email notification when a new blog is available.

Stuart Selip owns and operates Principal Consulting, LLC, an IT Strategy consulting firm that is a business partner of TIC Software. Prior, as the Chief Executive Officer of Luxoft’s Consulting Strategies unit, he managed delivery of IT Strategy consulting to Fortune 500/Global 2000 firms in the Financial Services, Insurance, and Media industries.

TIC Software, a New York-based company specializing in software and services that integrate NonStop with the latest technologies, including Web Services, .NET and Java. Prior to founding TIC in 1983, Phil worked for Tandem Computer in technical support and software development.

Works Cited

Gottesdiener, E. (2002). Requirements By Collaboration. Boston: Addison-Wesley.

Riether, N. e. (2012). Social Facilitation with Social Robots. Human Robotics Interaction Conference. Boston, MA: Association of Computing Machinery (ACM).

Sibbet, D. (2002). Principles of Facilitation: The Purpose and Potential of Leading Group Porcess. San Francisco, CA: The Grove Consultants International.

Tuckman, B. W. (1965). Developmental Sequence in Small Groups. Psychological Bulletin , 384-399.