Blog

integration and implementation of technology-focused business solutions

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

How to stay on budget with software upgrades

October 3rd, 2017

Estimating is one of the most difficult parts of our job. There’s natural tendency to treat estimates like promises. And in the software business, there are many reasons why a project might end up more expensive than estimated.

Here are a few things for customers to keep in mind when approaching a major software project. Understanding what features you need, knowing what you can afford, and being open to suggestions from an IT provider can make life a lot easier.

Know what you can afford

The key to getting the software you need and not breaking the bank is to be realistic about your budget.

It’s easy to put down on paper what you’d like to have. But in the software business, where you can’t touch or see what it is that you’re asking for, there’s a tendency to overshoot. Features sound simple enough to add, but each feature adds on cost and time.

Be open to change

Like a custom-built home, each feature that you add costs more money. If you’re flexible enough to know the difference between a must-have and a nice-to-have, you can get the most bang for your buck.

In some cases, features that you thought were necessary might prove too expensive. And in the long run, you may be able to get all that you need without those features. We work with our customers to decide what they need and what they could do without.

It’s important for our customers to be flexible. Otherwise, projects tend to go over budget and take longer to complete.

Don’t set an estimate in stone

Remember that ultimately an estimate is an estimate. Start with a realistic budget, but understand that there’s always a chance work will take longer and cost more than was originally planned.

Comments: None

How a little trust can start a great relationship

September 19th, 2017

Sometimes, a little bit of risk and some trust can be the start of a great business relationship. In this post, I'd like to show you how that concept helped both LSG Solutions and GET Imaging find a solution to an IT problem.

Taking smart risks

Not every deal is a safe bet, and we all know what a bad relationship is like. Knowing your strengths is the key to choosing the right amount of risk.

GET Imaging's system was built with Oracle Application Express, or APEX, which is a pretty standard framework. While we didn't know the full history of the customer's system, we knew that our experience with APEX qualified us for the job. We knew there was a good chance we wouldn't see anything we hadn't seen before in that system, but we didn't know that for sure.

We weren't the only ones taking a risk in this scenario. The client had invested 4,000 to 5,000 man hours in their current APEX system, and they had never worked with an outsourced IT solution before. Trusting someone else with their system was a huge step.

Regardless, they were willing to trust us enough to pay up front for 40 hours of work. If they were happy with the business, we could continue working together.

How we helped GET Imaging in 40 hours

With this project, our primary goal wasn't just fixing a single system. We also wanted to gain enough trust with the client that they'd continue doing business with us.

Using the allotted time, we first focused on gaining a high-level understanding of the APEX system's role in the client's business. Then we drilled down into the system's problematic areas and uncovered some big-picture problems that the client didn't know about.

Being able to identify fixes to these problems built enough trust with the client that they continued doing business with us.

Just enough trust

One of the primary issues we face with clients is that they have trouble trusting vendors. Sometimes, as in this case, it's because they were used to working with somebody in-house. In other cases, it's because they have been burned before by an outsourced vendor, and they don't want to get burned again.

Productive business relationships require just enough trust. GET Imaging trusted us enough to get a feel for how our services fit their business, and that became the foundation of an ongoing business relationship.

Comments: None

The importance of flexibility in an IT upgrade

September 5th, 2017

Technology often changes too fast for IT upgrade plans. If you aren't willing to be flexible, upgrading can be a real pain.

Lately we have been working on upgrading a client to an Oracle 12C database from a 10G database that was built around 2005 or 2006.

We drafted our initial plan to upgrade this client's system two years ago. But thanks to procurement lag and technology advancements, we've had to change the plan entirely.

Fortunately, our client is flexible. That's not always the case. Some customers are stuck on their original plan, and they have trouble coming to terms with the fact that today, technology can ruin your plans in the blink of an eye.

Staying flexible

Often clients stick to the original plan because they're afraid of price increases. Sometimes they have experienced what we call "death by change requests," where each change has required a little more money on their end.

A good vendor can help you stay flexible within your budget and adjust the plan so that you get what you need. But for us to make that happen, customers need to be flexible. In today's world, no plan is going to stay the same.

No matter how many paint color samples you see, the paint is always going to look different once you've put it on the wall. Likewise, your original IT plan is going to look different after a year's worth of technology advancements.

Ideally, you should be willing to do some re-prioritization or regrouping if a year has gone by. If you're forcing everyone to stick to an old plan, you're cutting off your nose to spite your face.

Tech changes too fast for stubborn planning

I once heard a frustrated CFO wonder when these technology advancements were going to slow down. The answer is maybe never. Bottom line is that the days of slow and static tech are long gone. In the blink of an eye, everything can change.

That's why it's important to be flexible when you're planning on upgrading systems. Why would you want to fight against changes that will improve your new system? Quit working so hard to be worse off than you were at the beginning. Embrace the flexible nature of technology and adapt your plan accordingly.

Comments: None

Defining success with the cast of characters

August 15th, 2017

In our previous blog, we discussed the cast of characters typically seen on an IT project. Knowing who they are and what they value helps project managers understand their varied perspectives.

However, understanding is just one part of the equation. The goal is a completed project that all team members identify as being successful.

But, how do you define success with these different personalities?

Set Expectations

Chances are, the cast of characters have differing expectations. It's important to know what they are and how they fit within the project.

Before the project begins, sit down with people individually and ask:

  • What do you hope this project accomplishes?
  • What are your expectations involving project milestones?
  • When will you know the project is successful?

As they answer these questions, use the time to discuss the overall expectations of the business and project managers. Find common themes between their expectations and others. Ask for their help in reaching those goals.

Identify the Points of Pain

Figure out the biggest pains or problems and make them milestones. Those have meaning. One person may have different pains than others. So, milestones may be created for individuals or departments.

When the milestones are met, celebrate with them and help the rest of the company see the value. Often, people in an organization don't recognize how wins in other departments directly impact their work as well.

An example of this is implementation of HR software that speeds up the processing of applicants in a manufacturing company. Obviously, the software directly helps the HR department with efficiency of hiring. However, the impact of being able to add new team members faster benefits the entire company and should be recognized.

Capture Mind Share

Many people do their best thinking and problem solving away from meetings. Yet, it's essential that their ideas are expressed and shared. It helps people feel engaged and heard, and it creates a flow of communication to keep the project running efficiently.

Here are a few creative ways to capture mind share from the entire team.

Running white board

Designate a large white board for this. Ask team members to write down any ideas, issues, or suggestions throughout the week. Go over the information on the white board at each project meeting.

Cross-functional team lunch

Often, people hang out with the same group of people every day. Change things up by organizing lunches for small groups from various departments. Ask them to discuss a specific aspect of the project in which they have visibility. Have them report out on that discussion at the next project meeting.

Understanding that an IT software project is about more than the mechanics is essential. Building a relationship of trust with all people involved is every bit as important, because success is defined by the people impacted.

Comments: None

Cast of characters during an IT software project

August 1st, 2017

Every project is different and so are the individuals involved. From large companies to small organizations, diverse IT needs directly impact day-to-day operations.

Before launching an IT software project, it’s essential to understand more than the mechanics. Start dates and end dates are important, but the true key to success rarely lies in the metrics.

The people who are impacted by the change are the ones who define success. So, understanding the people involved, their roles, and their expectations should be the highest priority.

Let’s meet the cast of characters you’re likely to see during an IT project.

The Idealist

Though it’s nice to have optimists and dreamers on the team, these folks can be a challenge of their own.

The idealist wants the project to go smoothly. They don’t want to deal with delays or roadblocks. In fact, sometimes it’s easier for them to hear what they want to hear than deal with reality.

Working with the idealist requires a bit of mining for information prior to the start of a project. Ask questions like:

  • What IT projects have impacted you in the past?
  • What were some problems with those projects?
  • How did you work through those?

The answers to those questions should give clues to how involved they were with past projects, as well as how involved they might be during the current one.

The Naysayer

Just as every cloud has a silver lining to the idealist, every cloud holds a thunderstorm to the naysayer. This person can spot the roadblocks before others see them. They are quick to point out problems with possible solutions as well.

This is also the person who may take every project delay as a sign that a project is doomed.
Though dealing with a naysayer may seem taxing, their perspective can be helpful. Be careful of having too many naysayers though, as they feed off each other’s negativity.

The Apathetic

This personality may be the most difficult, especially in an environment where every team member has the potential to add value. Their lack of engagement can create moral issues as well as limit the scope of the project.

To reengage the apathetic person, try to discover what they value. What are the things they find meaningful? Asking them to talk about a previous successful project they were a part of is a great way to get them talking. Then ask, “What made that project successful?”

This process doesn’t have to be boring or take a lot of people’s time. Everyone has their daily tasks to complete along with new responsibilities involving the project, so it’s important to make it as efficient as possible.

But, taking the time to create a plan and cultivate buy in can help put their minds at ease. Change in culture and processes has a huge impact on an organization and the people who work there. Take time to understand the cast of characters.

Comments: None

The 10% factor: taking longer than planned

July 4th, 2017

Routine I.T. fixes are usually quick, whether it be at the software, middleware or database level. Experienced I.T. professional service providers have a track record and method for resolving some of the most common problems.

However, sometimes despite everyone's best efforts, the perceived simple solution becomes a time-consuming fix. This is nerve-wracking for the I.T. professional, and frustrating for the client. Extra time required can cause business delays and create additional cost.

After years of working on I.T. issues both big and small, we can give a general idea for how long it will take to resolve common problems. But about 10% of the time, despite our experience and best efforts, the resolution takes longer than we anticipate. In our profession, we refer to this as the 10% factor, which every I.T. professional encounters.

Here are some things we do to prepare for this situation.

Communicate

When speaking with a client about their I.T. problem, we clearly communicate the possibility of the 10% factor up front. We let them know that while our goal is to resolve their problem in the estimated time period, sometimes issues take longer. We also know that our professionals have an extreme desire to solve the issue which we openly recognize as the catch-22 in managing expectations.

This conversation allows us to discuss appropriate expectations. We believe this is the first step in transparent, honest service to our clients.

Plan

Once appropriate expectations are set, we create a plan. This plan will include what the client desires if we encounter issues that will extend the time we originally estimated regarding the problem.

Some clients tell us to keep working on the issue until it is resolved. Other clients want to be notified immediately of any challenges the technician encounters in order to make decisions based on that conversation.

Discuss Risk

As human beings, we unfortunately often avoid discussions of risk. Yet, we know that effective planning includes identifying potential risk. We want our clients to have insight into the remedy for which they are hiring us, and educating them about possible risks and solutions is part of that discussion.

We want to help you resolve your I.T. issues so your business keeps moving forward. We believe communication, planning, and discussion of risk is the best way to tackle any issue.

If you have questions regarding this or any other I.T. challenge, please contact us to discuss how LSG Solutions can serve your business.

Comments: None

CONTACT

501 E. 15th St., Suite 200B
Edmond, OK 73013
(405)285-2500
info@lsgsolutions.com