It’s Time for a Tune-Up of your Mortgage Platforms

In the push to be able to conduct business during the pandemic, companies sought out new technology to improve their digital capabilities for both internal employee and external customer-facing work. There was a noted rush to select, implement and integrate new technology into the existing infrastructure to keep business moving along. For the most part, the purchase decision was compressed and triggered by the immediate need. As such, there are some decisions in hindsight that may cause regret and others whose terms are not as attractive as expected for a long-term relationship. Also, the selected technology could be a perfect fit, but the implementation may have taken shortcuts in the rush to deliver, and additional work may be desired to further refine the integration or customization to better meet the business needs. Even if no new technology was introduced, regular maintenance tasks were postponed during the pandemic, and training sessions canceled that were needed then but are imperative now.

As we move to the next stage of the pandemic, defining the work arrangements, returning in some way to a physical office location or just settling into a long-term remote work arrangement, it is a good time to take a breath and assess where your applications and infrastructure are today, and take a step back to prioritize key projects and next steps to move forward in whatever the new “normal” may be.

Vendor Management

Starting with vendor management and contract review, most organizations do a great job of vetting vendors during the purchase/selection process but fail to follow up on a regular basis to ensure the vendor and its practices maintain the necessary controls to keep their systems supported and your data protected. Given that your vendors had similar stressors maintaining business practices through the pandemic, it is a good time to re-assess their activities to ensure the expected levels of control and security are still in place.

This is also a great time to review your contractual agreements. Identify any agreements that will expire in the near term and start planning for the next steps which could be a replacement or re-negotiation for renewal. Identify any contractual terms that no longer meet your needs, e.g., on-site support with a remote workforce, and layout a new path and desired outcome before approaching your vendors. Ensure any needed or expected vendor certification/licensing is also up-to-date during your review process.

Infrastructure

Your infrastructure and its support should be assessed to ensure it is protected, sized, and supporting the organization. Are both hardware and software patches being applied timely? Are there are any components that need to be retired or are no longer supported? Assess whether changes are needed for growth or contraction. Are controls in place to ensure a secure environment for the data and organization? What has changed during COVID-19, and how has that impacted the operation?

There has been a move towards the cloud for a number of years, but the pandemic brought that shift to the forefront for many organizations. Questions to ask include: Is your selected cloud provider providing the service and support you and your organization expect and need? If outsourced, are you getting regular (and useful) reports about the health and security of the environment? Are any identified or contractual service-level agreements (SLAs) being met? Are there SLAs that weren’t defined but should be? Address deficiencies with your internal/external vendors or select new ones, as appropriate.

Software Technology and Documentation

Your software technology is critical to your success. During COVID-19, a lot of projects were put aside for more immediate “keep the lights on” activities. A review of what is listed in your backlog is needed to identify where (and if) issues with key functionality exist. Points of integration should be reviewed to ensure the exchange of data is being completed in a secure manner, seamless to the end-user. In general, complete an assessment to ensure you have the best combination of systems supporting your business operation. This process will ensure awareness of not only immediate needs but those that are just over the horizon. If software was selected in a rush during COVID-19, it’s a good time to look at the industry for alternatives to identify a better fitting solution or to identify enhancements to request of your vendor.

Documentation is an area that was frequently ignored during the pandemic (and other times). There is value to the organization maintaining documentation of your systems and practices. The application architecture diagram is a simpler diagram to create, but is critical to understanding the systems in (and out of) your environment and their interactions. Many organizations have graphical representations of their network, but not of their applications, interactions, and uses. The application architecture and other documentation facilitates communication and understanding within the organization and with your vendors.

Security

The last area that needs attention is one that should be foremost in everyone’s mind and that is security. Security encompasses people, processes, and technology. Attacks can come through any of these areas and vigilance is needed to stay protected. For people, it is important that any training sessions that were postponed during COVID-19 be re-scheduled to educate employees on such things as identifying spam emails and phishing schemes. Processes should be reviewed to ensure that information is being properly protected whether it is paper or digital throughout the process, and only appropriate data is being shared. Finally, the technology needs to be assessed. This can include a review of users and the level of access granted, ensure that anyone that has left the company has had their access revoked, that security levels are commensurate with the roles, etc. Identify any users that haven’t logged in for extended periods and determine if their access is required. Security surrounding applications should be reviewed to ensure that the current protocols are being followed, the complexity of passwords, the number of days between password changes, etc. Administration passwords should also be updated on a regular basis.

While all of the above would normally be considered business as usual, COVID-19 has irreparably changed what normal is. Work that has been postponed, canceled, or set aside should be revisited to identify what is still applicable to maintain a secure and functional operation for the organization and its user community.

Can you imagine a world without engineering? It’s a tougher question to answer than you might think. Many people do not actually know the extent to which we rely on engineering for our daily lives to function, and the amount of work that has gone into it by different types of engineers.

The discipline of engineering is one of the oldest, arguably as old as civilization itself. The first engineers were those who developed the lever, the pulley and the inclined plane. Egyptian engineers designed and built the Pyramids, and Roman engineers conceptualized the famous aqueducts. Today, engineering covers a broad range of disciplines, all devoted to keeping the “engine” running — a world without engineering would soon come to a standstill.

In a recent conversation, I answered the usual “What does CC Pace do?” question with my standard response regarding our services, to which she replied, “Oh, you’re process engineers!” Her response was compact, narrowly focused, and remarkably spot on. With people processes and systems processes at the heart of much of what we at CC Pace do, yes, we are process engineers, yet it had never occurred to me to describe us as such.

Quoting liberally from Wikipedia, process engineering focuses on the design, operation, control and optimization of a series of interrelated tasks that, together, transform the needs of the customer into value-added components and outputs. Systems engineering is a close corollary activity that brings interdisciplinary thinking to focus on how to design and manage complex systems, beginning with discovering the real problems that need to be resolved and finding solution to them. That’s what we do here at CC Pace in a nutshell.

Some folks make the mistake of thinking business processes are in place to only ensure internal controls remain strong and to make people accountable for what they are doing. In fact, business processes constitute all the activities your company engages in—using people, technology, and information—to carry out its mission, measure performance, serve customers, and address the inevitable challenges that arise while doing so. Processes determine the effectiveness and efficiency of your company’s operations, the quality of your customers’ experience and ultimately, your organization’s financial success.

At CC Pace, we pride ourselves in achieving organizational excellence by being the industry leader in business process and technology engineering. We are dedicated to driving innovation and delivering exceptional quality in everything we do. As systems and process engineers, we help our clients streamline, standardize and improve their processes to retain a competitive edge. You see problems; we see solutions.

I have enjoyed using analogies between baseball and software development in a few of my previous blog entries, so with Major League Baseball’s season underway, there’s no better time than now to write another baseball-oriented blog entry. But don’t fret, non-baseball fans, because this message, like so many others, applies to both life AND baseball.

In recent years, I’ve observed many software development teams engaged in long-term, multiple-release software development projects. I would classify these as projects incorporating stable, unchanging teams, spanning a year or more and challenged with navigating through fluctuations of tension – followed by calm – which usually accompany projects with multiple production releases.

An interesting and alarming behavioral tendency seems to have emerged – or more likely, I’m only now noticing it – with enduring, static teams working together on projects or applications spanning multiple releases. This behavior isn’t an obvious, tangible issue like a team member missing meetings. Rather, it’s a human behavioral trait that seemingly emerges unnoticed and isn’t uncovered – if it’s even uncovered at all – until it’s usually too late, after the damage has been done.

What is this negative tendency you may ask? And what in the world does this have to do with baseball? Well, it can be defined with many words or explanations, but for this blog, we’re using one word: LOLLYGAGGER. Trust me, as you will see, you don’t want to be called a lollygagger, as it’s definitely not a compliment or a term of endearment. And you certainly don’t want to be developing software with or managing a team full of lollygaggers.

thefreedictionary.com defines the verb ‘lollygag’ as follows: To waste time by puttering aimlessly; dawdle. This simple definition does not do proper justice to this word.

Side note: It would also be prudent to mention here that this behavior doesn’t seem to manifest itself on greenfield projects, or short-term engagements with newly-formed teams for obvious reasons – arrangements which usually permeate high-energy and team enthusiasm during the early ‘forming’ stages of team development (see Tuckman’s Stages of Group Development). This would make sense as a lack of enthusiasm is usually not a characteristic of newly-formed teams.

So, this odd linkage came to mind when the movie Bull Durham appeared on television a few nights ago, which – aside from providing the vision for this blog entry – is one of my all-time favorites. Critically acclaimed as one of the greatest American sports movies of all time, Bull Durham is a must-see for any baseball enthusiast. The movie is based on one person’s experiences in minor-league baseball and depicts players and fans of the Durham Bulls, a minor-league baseball team residing in Durham, North Carolina.

One gains a TRUE SENSE of how lollygagging can hurt any team watching one of my favorite scenes in the movie which casts “Crash” Davis, the wise, veteran catcher and the Bulls’ manager, known as “Skip” (of course). The Bulls are playing awful baseball, mired in a long losing streak, and the manager has run out of patience and ideas. Which takes us to the scene inside the Bulls locker room after yet another painful loss:

Skip: “I don’t know what to do with these guys. I beg… I plead… I try and be a nice guy… I’m a nice guy.”
Crash: “Scare ‘em.”
Skip: “Huh?”
Crash: “Scare ‘em. They’re kids, scare ‘em. That’s what I’d do…”

After a chuckle, and now armed with this ingenious managerial advice, “Skip” proceeds to forcefully assemble his unsuspecting group of apathetic ballplayers into the shower area, throwing an entire rack of baseball bats into the shower after them, which certainly draws their attention (and those watching the movie). “Skip” then barks out an epic rant that would make Earl Weaver proud:

Skip: “You guys… You LOLLYGAG the ball around the infield. You LOLLYGAG your way down to first. You LOLLYGAG in and out of the dugout. You know what that makes you? Larry!”
Larry: “LOLLYGAGGERS!”
Skip: “LOLLYGAGGERS. What’s our record, Larry?”
Larry: “Eight and 16.”
Skip: “Eight and 16. How’d we ever win eight!?!”

So, in summary, a hilarious scene from a baseball movie taught me early on that lollygagging is not a good thing. I am now seeing that it is also a bad way to start off the early stages of your software development project. Think about it – as a team, once we clear that release hurdle, our instinct is to stop, take a deep breath, and relax. We just hit a major milestone, and more than likely the team worked some intense hours, days, weeks and sprints leading up to the actual release. (No matter how good your team is or how well you apply agile techniques, the days leading up to a release are ALWAYS more intense than those at the outset of a project.)

Picture the scene: our big release is deployed over an entire weekend, and everyone arrives to work on Monday. Whatever velocity, urgency and momentum generated and sustained through the prior release has seemingly dissipated into thin air. Because our next release is several weeks or months out, a feeling of tranquility sets in, as if the level of urgency no longer exists. We have now become…wait for it…OH NO! LOLLYGAGGERS!

This period of relaxation, or lollygagging, poses many threats to the next phase of the project.

That next release schedule – which was planned and completed last week and is now posted on the team room wall for everyone to see? Unfortunately, that new release schedule does not include any extra time for and does not tolerate relaxation, tranquility, or LOLLYGAGGING in the early sprints of the next release.
Due to the team carryover (with little or no change in personnel) the work to be done in Sprint #1 of the succeeding release is also likely projected based on established velocity from earlier sprints (i.e., the previous release). A slow, unproductive start to the first few sprints will undoubtedly result in a negative cascading effect on the entire release. For example: your release plan calls for 200 points with another production deployment after 10 sprints, because your team has proven time and time again this is an achievable goal (i.e., team velocity ~20 points). Your first two sprints start slowly and end up totaling 20 points, which already puts the team in trouble and in catch-up mode. Nobody likes being in catch-up mode. And catch-up mode tends to have a snowball effect.
Unless the release plan provisions for it, don’t allow carryover from the previous production deployment (or any associated issues or complications) to bleed into the early phases of the new release. Lollygagging will set in if team members continually remain in the mindset of the preceding release – in other words, looking back and not forward. Make sure the page is turned quickly on the weekend of the release (i.e., over to product support) and not turned slowly in the following few weeks.

As mentioned earlier, this behavior isn’t usually noticeable early on, but in those last few weeks before the subsequent deployment, when things become hectic and crazy again, everyone will wish they all hustled a bit more in the early weeks of the project.

Don’t get me wrong – celebrate the occasion! We’re not robots, and I’m a firm believer in recognizing and/or celebrating milestones at the end of a sprint or even better, after a successful production deployment. Those team milestones and achievements that we recognize working as teams are one of my favorite concepts of Scrum. But the party, or I should say, ‘mental break’, should not last for four weeks.

Here’s another way to think of it, and yes, we’ll use another baseball analogy. There is a baseball maxim which is often spoken at this time of the year. When a baseball team with high expectations opens the season with a poor start, you’ll often hear the following quote (or something similar):

“You can’t win the pennant in April, but you can certainly lose it.”

Keep that in mind when your next release starts – you can’t guarantee a successful project or production deployment in the first couple sprints of your new release, but if you come out of the gate slowly and LOLLYGAGGING, things can certainly come off the rails in a hurry. And everyone will be paying the price a few months later as the release date draws near.

The solution is simple, right? Make “Skip”, “Crash” and me proud, and just DON’T BE A LOLLYGAGGER!

Pete Rose, aka “Charlie Hustle”, was certainly not a lollygagger. He surely wouldn’t allow any of his teams to lollygag through the first few sprints of a release.

The Durham Bulls, on the other hand, captured the true essence of lollygagging. I can assure you that in this scene, only one or two people were actually concentrating on baseball.