integration and implementation of technology-focused business solutions

Building trust with our clients

March 6th, 2018

Trust is important in any partnership. We know that some of our clients have full trust in us from the beginning, whereas we need to constantly earn and keep that trust with others. And that’s okay. It’s part of doing business, and we always strive to earn and keep trust over time with all of our clients.

Here are a few factors that contribute to building trust with clients, especially for IT companies.

Ensure everyone is okay

This may sound like an odd piece of advice, but it’s a concept we use a lot. It’s a way to approach communication with other people that focuses on ensuring everyone feels comfortable in the interaction.

One of the biggest ways to make sure everyone is okay is to avoid jargon. And there’s plenty of jargon in the IT world! In the old days, we would walk into a meeting with a client and speak our IT language. But if they didn’t understand that IT language, we ran the risk of making the client uncomfortable.

Most people don’t want to raise their hand and admit they don’t understand something, which can lead to significant confusion down the road. By making sure we explain things in non-technical terms at every step of the process, we help our clients feel more comfortable with the interactions and with the decisions they need to make.

Put yourself in their shoes

Everyone’s professional background is a little different, even if they hold similar job titles. Some IT directors have a technical programming background but are less comfortable with other aspects of IT, whereas others are experts in network administration but less confident with certain software systems. There's a wide range of prior experience among people in every role, and it’s important to understand where your client is coming from.

Putting yourself in their shoes also involves seeking to understand the bigger picture. What else is going on at the company or in their IT department that might create stress or concern for that IT director (or other point of contact)? Ultimately, you want to make the project and your interactions about them and not about you, so it helps to understand the bigger picture.

Communicate with transparency

I’ll admit there have been times I avoided having difficult conversations. It’s pretty natural for most people to want to avoid conflict, but sometimes you just have to handle it. Companies who work with a strategic IT partner often have large projects that are critical for the company’s success. It’s important for their IT partner to be open and honest when communicating about that project to ensure the best possible outcome.

This also includes clear communication and thoroughly explaining anything the client might not understand. By taking the time to communicate with them, they’re better able to communicate with internal audiences about the value of the project you’re working on.

If you could put a dollar figure on what companies waste due to mistrust and lack of productivity related to mistrust, it would be huge. Trust is critical! You can’t turn on a switch and immediately gain someone’s trust. There are some scenarios where trust can be built quickly, but most of the time it’s a gradual and worthwhile process.

Comments: None

The importance of quality user interfaces

February 20th, 2018

With the number of web and phone applications available today, most people experience a number of different user interfaces on a daily basis. Most consumer-focused interfaces are pretty nice, but a lot of enterprise or internal company interfaces are not.

In my years of working with many different companies, I’ve seen some crazy things for user interfaces. Sometimes I find myself asking if the developer was colorblind, and other times I’m simply baffled at the number of steps required to accomplish a single task in the system. If I weren’t walking through the system with someone who had been using it for years, I wouldn’t even know where to begin to find the necessary information.

Developing a user interface is about more than just how it looks. It’s also about information flow. Do the menus make sense to the user? Does information in the system flow in a logical way for that specific business? Can a single task be accomplished from a single menu, or does it require three different menu options to do one thing?

Yes, the design matters, too. Some developers don’t understand the importance of a clean interface. But that’s sometimes what you get when a “bits and bytes” developer creates something for an entire company to use. It makes sense to them as a developer, and they don’t realize that it’s difficult for a non-developer to use. But many enterprise user interfaces are used by hundreds of non-developers every day!

A lot of companies continue to foster terrible user interface design either because they simply don’t know it’s terrible or they’re unwilling to invest the time (or money) in something better. But there’s a cost to poor user interface design-both in terms of employee frustration and in actual time spent using the interface.

How much money do you lose when employees can’t figure out how to use your system? Or when they have to click through multiple different menus to pull one piece of information? It’s an intangible cost, but it’s there.

In recent years, I’ve seen an increased awareness of the importance of user interfaces, although it’s still going to be quite a while before every company has a quality user interface. But new developers are leading the charge because they’ve been exposed to so many consumer user interfaces. They realize that enterprise interfaces deserve the same level of quality and ease of use. And that’s a good thing!

Comments: None

Continued support for Oracle Forms and Reports

February 3rd, 2018

Oracle has always been known as a database company, but there came a point in time where they recognized a need to provide developers with additional tools for developing software that would easily integrate with the Oracle database. Thus, Oracle Forms and Oracle Reports came into existence.

Oracle Forms allowed developers to create data entry forms with fields that easily map to the database. Oracle Reports were also pretty straightforward with reports based on SQL select statements like most reporting systems. At the time they were released in the late ’80s, the formatting was pretty limited since they were running on screens with a black background and green font.

When initially launched, the systems were installed on each individual computer. It took time and effort to complete each install, and if someone got a new device, it had to be installed again. All of the heavy lifting was done by the individual computer, and the applications took up a significant amount of memory.

Over time, Oracle realized that things were changing and the applications needed to be web-based. They made that switch in the mid-to-late ’90s. Organizations no longer had to install the system on each computer, but rather simply accessed it by clicking on a link. The computer would bring up a Java application while using it, and once finished, the computer would let go of all those resources.

Despite some improvements over time, Oracle Forms and Reports are technically considered legacy applications at this point. Oracle has clearly stated that the current version of Reports is the terminal version, which means they will no longer invest in improvements to the system. While Oracle Forms hasn’t been designated a terminal version, there are better alternatives available today.

If building a new system, we would recommend choosing different tools to accomplish both forms and reports. But what about those companies that have a significant investment in those systems currently?

For some companies, it makes sense to switch to an entirely new system and migrate all of the data. Others may not be willing or able to take on such a transition. We had one client who had built an in-house ERP (enterprise resource planning) package over the course of about 15 years using Oracle Forms and Reports. They had hundreds of menu objects, about 1,200 forms that totaled nearly 5,000 pages, and 130 reports. The cost to fully convert was close to $1 million, and they couldn’t afford it, so we continue to support their existing systems.

As older employees retire, many companies are finding themselves without the internal knowledge to support complex systems built with Oracle Forms or Reports. It can be challenging to find an IT company that can support legacy Oracle systems, but it’s one of the many services we offer. If you are using Oracle Forms or Reports and need support to keep your systems fully functioning, contact us today for more information.

Comments: None

Managed services for Oracle Database Appliance

January 16th, 2018

Oracle Database Appliance is a powerful system. It’s pre-built and pre-configured, and it integrates the software, storage, computing, and network resources needed for a continuously available database system. The system is built with redundancies so that it continues working even if one component fails.

The problem with Oracle Database Appliance is that it can be a bit of a behemoth to manage for some organizations. Over the years, we’ve seen two things happen with organizations who use Oracle Database Appliance.

First, staff turnover happens, and the people involved in the initial purchase are gone. The people left at the company to support it weren’t involved in the purchase, and they may not have the skills to manage and maintain it. As new releases and patches occur, there can be some weekend maintenance required, and the company may not have the staff necessary to cover it.

Second, it can be hard to hire a staff person with the right combination of skills to manage Oracle Database Appliance. Since it’s multiple technologies in one system, it doesn’t fit cleanly with one specific job title in IT. Is it the network administrator? Database administrator? System or server administrator? It’s actually all of those positions in one, but most organizations aren’t structured in a way where all of those positions work together on one system.

When it comes to managing Oracle Database Appliance, many companies choose to outsource that support. By outsourcing, the company is guaranteed to have the necessary skills and confidence to maintain the system, and they have someone to handle weekend upgrades and any troubleshooting that’s necessary.

At LSG Solutions, we offer a monthly managed services package for Oracle Database Appliance. We support the database and any patches or upgrades, as well as any hardware issues that may occur through both on-site and off-site support. We work with companies to identify the capabilities of their existing staff and then provide supplemental support to ensure proper management and maintenance of the Oracle Database Appliance system.

If your company uses Oracle Database Appliance and wants to ensure that the systems remains fully functional, contact us today for more information.

Comments: None

The value of integrating kanban and scrum-agile

January 2nd, 2018

In the world of software development, most organizations use the scrum-agile approach or a kanban approach. But it's not unusual to find organizations that wonder if the other way might be better.

That usually happens with organizations that are entrenched in the way they develop software via scrum methodology, and they start to wonder if kanban might be a better approach.

In some cases, a software company will look at the alternate solution and decide to pick and choose some features that can be applied to the process they’ve already built. That’s exactly what we’ve done at LSG. We’ve taken what we consider to be the best of both worlds and combined them into a process that works for us and our clients.

Scrum-agile and kanban aren’t competitors in terms of software methodologies. They’re simply two different ways of doing things, and pieces of each have valuable application in the software development world.

For example, scrum-agile tends to focus on getting things done and marking them off the list. You may end up with a team of developers who are so focused on clearing out their tasks that it’s somewhat like when you clean four rooms in your house by throwing everything into another room. It’s out of sight and out of mind for the people who checked it off their list, but something still needs to be done to finish the job.

Kanban focuses on the importance of looking at the overall flow and the complete picture, not just one task at a time. The kanban approach encourages periodic review of what’s still incomplete and why, and it’s amazing the little reasons something may be incomplete. Brad needs to talk to Sharon who needs to talk to Mike who needs to talk to Lisa. No one really knows if the task if done or not, and before you know it, two months has passed.

Both scrum-agile and kanban are swim-lane oriented and focus on moving things from left to right until complete. But adding kanban helps give a better view of the work in progress and focuses on continuous improvement. It’s not just about “let’s get it done,” but also about, “how can we do it better?” While it may seem like a new approach for some in software development, it’s been proven successful again and again in lean manufacturing.

For software companies that haven’t implemented either approach yet, I recommend going straight to the kanban mindset and implementing that first. Then you can go back and look at scrum to see if there’s anything extra to add from that methodology.

For software companies already using the scrum methodology, adding kanban doesn’t mean scrapping everything you have-it simply means modifying your process and adding the pieces that work best for your organization.

We’ve found an integration of both methodologies to be highly successful for our team at LSG Solutions, and we encourage other software developers to consider integrating them as well.

Comments: None

How Kanban transformed our company

December 19th, 2017

At LSG Solutions, we’re firm believers in the fact that systematic processes lead to more predictable outcomes, and that lessons learned create even more predictability over time. It’s a lesson I learned while working at a manufacturing plant during college. They allocated time for employees to think about process improvement and implement ideas, which had a significant impact on the company over time.

These process improvement strategies, which are frequently used in product engineering and manufacturing, continue to trickle down to the software development process. The software development process isn’t always predictable, but there are still steps you can take to improve the process.

For us, Kanban is less about the tool and more about the philosophy. It’s a way of thinking that embraces the need to think and reflect on projects when they’re complete and identify areas for continual improvement.

There are a lot of great things about Kanban and how it has impacted our company. Here are my top nine.

  1. Creates a more efficient flow of work. Everyone can see the visual layout of tasks and projects.
  2. Allows people to be thinkers. It builds reflection time into each project to ensure that important steps aren't overlooked.
  3. Focuses on implementing manageable change, not dreams. There’s still a place for the dream projects, but projects have to be broken into manageable chunks.
  4. Empowers all levels to lead. If someone notices a bottleneck in the process, they can change it.
  5. Prevents spreading people too thin. If too many things are in progress, there’s not enough time to ensure proper completion.
  6. Encourages open communication. It creates transparency around the issues, especially those that affect efficiency.
  7. Takes assumptions and guess work out of the equation. Instead, it encourages asking questions to seek clarity.
  8. Encourages people to be savvy in the theories of risk, processes, and workflow. Many people are afraid of risk, but it’s necessary in the business world, and it’s easier to manage when you understand it.
  9. Helps make decisions, predict outcomes, and compare to actual results. You can’t improve what you don’t measure, and Kanban helps us measure what we do.

There’s no magic scientific formula for creating a perfect software product, but there are some things you can do to influence the outcomes. At LSG Solutions, Kanban has changed the way we think and approach software development. We have in-house software developers who understand risk, workflow, and processes, which is something that differentiates us in the market.

Comments: None

The importance of finishing what you start

December 5th, 2017

There was a time in the past (and still today at some companies) that software developers and users suffered from shiny object syndrome. Big ideas got tossed around and started, but projects didn’t get finished, or they looked dramatically different than the original idea. Often those projects started with too many requirements or a lack of clarity around the end goal.

The issue of shiny object syndrome sparked many companies to begin using the agile-scrum approach for software development, but it also created a broader awareness of the need to prioritize. By breaking projects into smaller pieces and creating clear priorities for those smaller pieces, it’s easier to set expectations for what can be accomplished in a given period of time.

This approach in my work life carries over to my home life. I frequently tell my kids to finish what they start. I also tell them they shouldn’t start a project unless they believe they can finish it. Those projects might be a grand idea for a Lego build, or any other project they dream up, as their brains are always dreaming up great ideas.

For my kids, there are two things that typically interfere with completing such projects: they get frustrated and decide the project is too hard or they simply get distracted by something else. The same is true in the business world. It’s human nature, and it starts at a young age.

I’ve seen businesses start way too many software application endeavors and then assign one or two developers to each endeavor. Then the projects just go on and on. The organization claims the projects are a top priority, but they never get completed, which frustrates the developers and the company’s leaders.

Whether it’s a business or your child’s Lego project, our human nature is to start too many things and not finish them. Then we end up extremely busy, but highly unproductive because we can’t figure out how to prioritize the work flow. To counteract that, the people involved need the ability to determine the flow of production.

At LSG Solutions, we’ve fully embraced both the agile-scrum approach for software development and the importance of finishing what we start. And we’ve found a great tool to manage it, which we’ll tell you about in our next post.

Comments: None

Why we use an agile-scrum approach for software development

November 21st, 2017

In the IT world, there are many projects that are too large and complex to be successfully managed in one piece with a defined single point of completion. Once the industry realized this in the early 2000s, the process of agile development was born. Agile development is about ongoing delivery and continual improvement of software, rather than that single end point of one large project. It also helps break down large projects into smaller, more manageable steps.

At LSG Solutions, we have been using an agile software development approach for more than a decade. We take a large project and break it into smaller pieces with primary units that last about one month, which are known as a sprint. So instead of running a marathon, we’re running a series of shorter sprints to accomplish the goal.

Every project is different, so the number of sprints will vary. All tasks for all projects are put into a sprint backlog, which means it’s waiting to be assigned and worked into a specific sprint. We’re continually adding things to the sprint backlog and then working them into sprints, which makes it a constant work in progress that stimulates both the mind and the technology. We use a specific software (Atlassian Agile Jira) to manage the assignments and organize them into sprints.

Scrum, which often goes hand-in-hand with agile, is an iterative approach. Each month-long sprint involves a day or two of planning and approximating effort. Each day has a short meeting to discuss progress and impediments. And at the end of each sprint, we reflect on lessons learned.

The scrum approach identifies the people who are actively involved in a task and those who are committed to or accountable for that task. Three specific roles are assigned: scrum master, product owner, and team member. The scrum master runs interference and acts as coach throughout the process. The product owner is the staff person or group who will be using the software system, which means IT doesn’t own the system in this accountability model. And the team members are the developers and subject matter experts who will be working on the project.

Product owners are involved extensively in determining the order that pieces should be worked, or the prioritization of smaller pieces as opposed to working on large pieces with little visibility. They are also in charge of the entire product backlog, although the team is involved in setting expectations as to what can be accomplished in each sprint.

With large pieces broken down into smaller pieces and assigned to different team members, it’s much easier to measure progress on a large project. When we complete estimates each month during sprint planning, we’re estimating those smaller pieces that can be measured along the way.

With each sprint, we have clearly defined goals for delivering increments of software. We use this process because it helps our clients have visibility into the software production process as opposed to waiting and wondering about their project’s status.

Comments: None

Reflecting on the days of pre-agile-scrum software development

November 7th, 2017

Long before agile software development started to mature, LSG leader Alan Sheppard recognized that there were significant challenges in the way things were done. Organizations struggled to create and manage a product when trying to balance the software developers’ approach, the business expectations, and the conservative risk managers’ requirements. Too many people couldn’t see eye to eye on how to approach and address the engineering of a large mission-critical product.

Some software developers had shiny object syndrome and never finished what they started, despite starting many tasks. Other developers could not adapt to the varied skills of their peers.

Some business owners or leaders just wanted it done, regardless of whether or not “done” was feasible. Others in the business world truly never knew what they really wanted done, and the right visionary people were too high up to get involved.

Some wanted every pre-defined feature and/or requirement available plus all sorts of new requirements. Those new requirement requests typically came as a result of developers explaining a perceived bigger, better, cooler way to do something.

In the midst of all these different expectations and approaches, the key end users often worried that the system would no longer be funded after the initial go-live, so everything would have to be rolled into one opportunity. Back then, the mindset of having multiple, ongoing opportunities didn’t exist.

Most expected the design phase to be a one-time start-stop effort, yet parts were moving all over the place during the entire project.

Then there were issues with accountability where stakeholders would blame the software developers if anything went wrong instead of focusing on measuring progress and quality. And if something went wrong, software developers would blame the end users for miscommunication about the requirements.

As the project continued, tensions would rise in the development team due to irrational constraints from a list of hopes and wants that conflicted with hard deadlines and limited funding.

Back in the late ’90s and early 2000s, IT software projects took big hits due to poor poor project management and software development processes. People in the industry learned many extreme lessons, yet some of these same obstacles still have to be addressed today.

LSG has been pro-agile and pro-scrum development since 2007, and we work closely with all of our clients to create clear expectations and efficient implementation of software development projects.

Comments: None

Understanding software estimates based on time

October 17th, 2017

We previously explained that a realistic budget based on a realistic understanding of the product is the best recipe for a realistic estimate.

However, budget is not the only consideration. You also have to consider the time that it will take to complete a project and how your request for proposal can influence time.

Some features require more work to add

You may want that special software feature for your business, but in reality, that feature is step 6 out of 10. Other software functionality needs to be built before the feature you want can be used. More steps mean more time. More time means more money.

This is a big reason why it doesn’t make sense for a software company to quote a block of hours without both the estimator and customer having a complete understanding of the project needs.

In some cases, customers don’t know how much time is involved. That’s why estimating hours for a project is difficult, and why you shouldn’t consider an estimate set in stone.

More people doesn’t equal less time

There’s a myth out there that adding more people on a project will reduce the amount of time it takes to complete. That’s not the case. Typically the issue is not that there aren’t enough people doing the work. The issue is the complexity of the work requested.

Deadlines and timelines don’t always match

The most difficult part of estimating a project is matching our customers’ deadlines with the amount of time that it will take to complete a project.

Sometimes, these deadlines are aligned with time-sensitive needs, but completing the project in its entirety might overrun that deadline.

In these cases, customers must either push out their deadline or be okay with launching software that isn’t fully built out.

It’s important to choose a technology partner that values open dialogue about such projects so both parties know what’s required for successful and timely completion.

Comments: None


501 E. 15th St., Suite 200B
Edmond, OK 73013