development addressing the it needs of companies n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
How To Avoid Failure With Your ASP.NET Software Project? PowerPoint Presentation
Download Presentation
How To Avoid Failure With Your ASP.NET Software Project?

Loading in 2 Seconds...

play fullscreen
1 / 14

How To Avoid Failure With Your ASP.NET Software Project? - PowerPoint PPT Presentation


  • 17 Views
  • Uploaded on

For more details call us at 603-726-5058 or visit - http://www.keenesystems.com/Expertise/ASPNETWebApplications.aspx

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'How To Avoid Failure With Your ASP.NET Software Project?' - marryljsmith


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
development addressing the it needs of companies

Development

ADDRESSING THE IT NEEDS OF COMPANIES

focus

How To Avoid Failure

With Your ASP.NET

Software Project

In today's world, whether you're

starting a new business, upgrading

your business processes or

revamping your business as a

whole, web technology has to

become one of the leading factors

to be considered. To stay ahead of

your competition you have to

constantly innovate and find new

ways to add more value for your

clients. From product development,

to sales, to delivery and to support,

a coherent, integrated software

solution enables your business to

not only start successfully, but to

expand that success as your

business grows. That all starts by

developing a software project plan

that will give you not only what you

need now but also that necessary

future expandability.

If you want to ensure success in

your ASP.Net software development

effort then you need to follow

these 10 steps to project planning.

1. State the Goals

As in any endeavor in life, whether building an enterprise software solution or building a

house, the first step is always determining the requirements and clearly stating the goals

of the project. Sometimes people jump too quickly into the details without first

pinpointing the real issues in an organization. Describe your vision of the project by

answering the question “What is the real problem we are trying to solve here?”

Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

think about current and future technology

Think about current and future technology: Computers are faster, servers more

powerful, storage less expensive and more flexible and access is more portable

than ever before. Between Moore's Law and the continuing pressures of business

needs, new ways to leverage technology will continue this trend. Today,

smartphones, tablets, and wireless connectivity are redefining how data is

accessed.

Here are some questions to ask yourself to assist in identifying how new

technology can help you reach your goals:

What is new and trending that can benefit you?

What pieces of today's technology world can you use now such as mobile

devices?

Who will use these devices and how will these technologies integrate into

your organization?

With a great intranet, anyone in-house can get to what they need easily but if

your business revolves around salespeople working around the country or

overseas, then internet accessibility to data is going to be an absolute necessity.

It’s important to identify major architectural decisions like this up front.

Your stated goals will become the foundation upon

which you will build the rest of your project plan.

They will give you clarity and purpose to ensure

project success. One way to achieve this is through

S.M.A.R.T. Goal Setting. SMART refers to goals that

are Specific, Measurable, Achievable, Realistic /

Relevant and Time Framed.

Specific

You need to be very specific in your goal. It’s not good enough to just say “We

want a faster system.” Instead, specify that in real terms, for example “We want to

be able to handle 500 concurrent users.” Or “We want to sign up 2500 new

clients.”

Measurable

Goals need to be measurable. The project goals need to be reviewed periodically

during the project planning process to make sure that proposed solutions align

with goals and scope creep hasn’t stepped in. Likewise progress towards goals

must be measured during implementation and a post-delivery analysis of the

project goals will tell you if you achieved success or not.

Achievable

It must be physically possible to achieve the goal.

Realistic

Just because a goal is possible doesn’t necessarily make it realistic especially

when viewed in the context of staffing, budget, technology and time constraints.

“S.M.A.R.T goals are:

Specific

Measurable

Achievable

Realistic / Relevant

Time Framed”

Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

relevant the goal needs to be relevant

Relevant

The goal needs to be relevant. You’ve probably heard of the 80-20 rule: As a rule

of thumb 80% of outcomes can be attributed to 20% of the causes. Focus on the

20% of things that will make the most relevant differences in your organization

given the resource constraints you have.

Time Framed

Setting goals to a time frame gives the goals structure. Open ended goals rarely

succeed. Now armed with clarity and purpose and a full understanding of your

end target, you are ready to start filling in the details of how you are going to

achieve the goal.

2. Identify the Actors/Roles

Who will need access to what data and how do they need

to access it? Each actor plays a different role in the

company, has a different view of the data and different

levels of access. For example, access granted to the

executive will likely be different than that granted to a

salesperson.

Some examples of actors are:

Salesperson

Accountant

Executive

Department Manager

Machine Operator

Individuals (actors) in an organization often fill multiple roles, especially in a

small company. So it’s important that you make a distinction between the role

and the role-player. The terms actor and role are not interchangeable. Just like in

the movies the actor Jack Nicholson plays the role of bad guy in one movie

(Batman) and then the role of good guy in another (The Bucket List). So don’t fall

into the trap of trying to define a system for a specific individual but instead for

each role that the individual plays.

3. Identify Processes / Data Flow

Next identify the business processes and how data flows through the

organization. Another term for this is “Use Case”.

Use Case (n) - “a list of steps defining interactions between an actor

and the system.”

Each actor will have a different set of tasks that they need to perform to do their

job. Identify each of these tasks for each of the actor’s roles. This information

“Actors are people

who make decisions

and take action on

the data in the

system.”

Use Case (n) - “a list

of steps defining

interactions between

an actor and the

system.”

Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

will be critical for the next step defining

will be critical for the next step (defining the data). For example, a salesman may

be entering sales data, running sales reports, and accessing client data whereas

the executive may just be interested in high level reporting. Each task may have

several steps from beginning to end and may require several complicated

screens. All of these steps must be documented. Some of these steps may be

identical to current manual processes in the organization but others will require

process reengineering in the context of the new capabilities made possible by the

new software system and new technology such as mobile devices.

You may have more processes in your organization than you realize. It’s often

very helpful to map these process flows pictorially. This is especially helpful in

conveying your design concepts to the reader of your design document. A good

tool for this is Microsoft Visio.

“Process Flow

Diagrams allow

people to visualize all

of the steps in a

complex process.”

An example process flow diagram produced with Visio

Be sure to think through of all of the possible scenarios for each given task an

actor performs. In very complex scenarios with lots of exceptions and decision

points it’s helpful to further define a process with a flow chart to graphically

depict the business logic of the process. This makes it significantly easier for the

reader of the document to grasp complex logic. Microsoft Visio can be used for

this type of a drawing too. Typically flow charting the logic of an application is a

very tedious task so it is usually reserved for only the most complex and critical

portions of an application.

Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

flow charts are tedious to produce

“Flow Charts are

tedious to produce

and are usually

reserved for only the

most complex and

critical portions of

an application.”

An example flow chart produced with Visio

4. Define the Data

Next, define the core database requirements identifying all data to be captured.

When planning any software project, the database will be the core of your

business information flow and getting it right the first time is critical to the

success of the project. IT business processes all revolve around data: storing it,

manipulating it and making use of the results in all aspects of your business.

This means customer data, product data and shipping data all have to co-exist in

a platform that enables everyone in your business to access the data they need,

quickly, securely and easily.

Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

the use cases defined earlier will dictate what

The use cases defined earlier will dictate what data needs to be captured and

manipulated.

First, the major tables need to be identified. Each table will hold like-type

records. Table examples would be things like:

Customer

Company

SalesPerson

PurchaseOrder

PurchaseOrderDetail (a line item on a purchase order)

Second, each record will have a number of “fields”. For example, fields in a

Company table may include:

CompanyID

CompanyName

Address

City

State

Zip

PhoneNumber

Third, relationships between the

tables must be defined.

For example, a PurchaseOrder record will have several child PurchaseOrderDetail

records each representing a line item on a purchase order. This is called a

parent/child relationship or a one-to-many relationship. All of these relationships

must be identified and architected in such a way as to allow for proper reporting

and expandability of the system in the future. A poorly designed database will

lead to a whole host of problems down the line.

There are a number of tools on the market for designing a database and

producing a nice database diagram during the planning stage. But one of the

best tools we have found is to use the database server itself. We find it is just as

easy to create the actual database in SQL Server during the project definition

stage. And there are a number of advantages in doing it at this time:

You can define every table and every field

You can specify the keys of each table

You can specify the relationships, such as parent-child, between the tables

You can enter some dummy data and actually test complex queries to be

sure you can produce the types of reports that you want

You can have SQL Server produce a diagram that you can place in your

design document

and best of all, when you start moving out of the planning phase and into

the coding phase, the database will already be built and ready for the

programmers to start using!

“The database will be

the core of your

business information

flow and getting it

right the first time is

critical to the success

of your project.”

Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

fact a common reason for software project failure

“FACT: A common

reason for software

project failure or

cost overrun is

because not all of

the screens were

identified and

designed during the

planning stage.”

An Example Database Diagram produced by SQL Server

5. Mockup the Screens

Next you will need to translate the needs and tasks of each actor into a series

of screen mockups that allow them to perform each task that their job dictates.

The screens also define the flow of each activity. To properly plan a software

project *all* screens in the system must be identified. Not Identifying all of the

screens leads to grossly underestimating the amount of work needed to

complete the system. Often people mockup the public facing portion of a

system but neglect to design the back end. Depending on the situation the

backend may even have twice as many screens as the front end.

The screen mockups have the extra added benefit of involving the system

stakeholders and future system users early on in the process. Often users

Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

cannot visualize how the system will work

cannot visualize how the

system will work.

Remember, they are experts

at what they do for a living

but not experts at software

design. They’ll have a hard

time digesting a 100 page

technical specification and

often do not have the

technical vocabulary or

communication skills to

describe what they want and

more importantly what they

need. You literally have to

paint a picture for them. The

more visual it is the better the understanding will be and the better the

feedback you will receive during the planning stage. Mockups make the

proposed system seem real to the users for the first time.

A good mockup will show all of the widgets on each screen and have an

“Screen Mockups

help end users to

visualize the system

design. Mockups

make the proposed

system seem real to

the users for the

first time.”

explanation of what’s going on

with the screen. One could use

Visio for doing the screen

mockups but an even better

tool can be found at

www.Balsamiq.com. We’re not

affiliated with Balsamiq, but we

especially like this tool because

the mockups are super easy to

make and look like hand

drawings. Unlike a Visio

drawing, a hand drawing-like

screen design reinforces the

concept that the user is looking

at a mockup and not the final

product. That’s important

because if a mockup looks too real some users can get bogged down in things

like color schemes and other minutia detail. At this stage you just want them

focusing on functionality and flow

not how pretty it looks. You need to

get the users to buy into the solution

early so you can verify the system will

meet their needs.

This strategy of involving the users

early in the project produces a better

product and reduces the natural

resistance to change when the new

system is fully rolled out. A user is

much more likely to accept a new

system that they helped to define.

Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

6 identify integration points another part

6. Identify Integration Points

Another part of your plan will be to identify all parts of integration. Often new

systems do not happen in a vacuum. That is, they will need to retrieve data or

pass data to some other software system that already exists. Each of these

integration points needs to be identified; not only what data is to be

transferred but also an explanation of how and when it is to be transferred.

Sometimes, during the planning

stage, the method of communication

between two systems is completely

unknown and requires a proof-of-

concept prototype of passing data

just to discover what’s possible. It’s

much better to find out your

proposed integration approach

doesn’t work during the planning

stage before you design a complete

architecture around it.

Some examples of integration would include:

 Web Service calls: A web service is a method of bi-directional

communication between two different software systems. They may be

located in the same building or be separated by continents and don’t even

have to use the same technology. The web service “publishes” the

specifications of its interface so the system on the other end knows how

to communicate with it. Think of a web service as a little program that’s in

charge of transferring data between two systems and hiding all the

complexity of the internet plumbing from the programmer.

 Direct Database Access: This type of integration involves directly

accessing the database of another system. If the purpose is only to read

data from the other system then there aren’t any problems here. However

if the other system needs to be updated, extreme caution must be

exercised. If a database is updated directly it may create a problem with

the integrity of the data if done incorrectly. For example, if the database

design requires that 4 records be simultaneously created in 4 different

tables when you add a new client record and you only create 1 of those

records then you may get the database out of synch. This sort of problem

is normally averted by calling a stored procedure that creates all 4 records

at once. The greater the complexity of the database the more chance

there is of creating a problem. So it is important to understand and define

exactly how you are integrating with an existing database in a safe way.

 Importing of files: Often direct integration with another system is not

possible because of differing technologies, lack of accessibility, cost, etc.

In those cases a 2 step process is the easiest solution: 1) Export the data

from one system into flat files and 2) Import them into the other system.

The file format of the exchange will need to be defined. In some systems

this entire process of exporting and importing can be automated.

“New systems often

need to integrate

with existing legacy

systems or entities

external to the

company.”

Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

7 write a test plan the lack of a test plan

7. Write a Test Plan

The lack of a test plan is why so many systems go live loaded with bugs. Each

programmer needs to do unit testing on their individual part of the

application but then it needs to be handed over to the testing team for end to

end testing. This is because when testing, it is human nature to overlook

details in an application that you wrote yourself because you’re too close to

the problem.

Programmers have a tendency to use the same test data over and over while

they’re writing code. Having an independent tester ensures better quality. But

how does the tester know what to test? That’s where the test plan comes in.

It will describe how the application is supposed to work and what tests can

be run to prove that it works as expected. The test plan spells out the criteria

for user acceptance.

8. Identify Go Live Issues

Some brand new systems can simply be turned on when ready. However

others, especially ones that are tightly integrated with another system, may

require a very complex go live procedure to prevent any down time in an

existing live system. The entire process needs to be thought through,

documented and contingencies identified should any unexpected problem

arise during deployment.

Go live plans are particularly important for sites that have high traffic, such

as ecommerce sites. An outage of even a few minutes could cost many

thousands of dollars in lost revenue.

9. Do Time Estimates

This is one of the toughest parts of a software planning project because it

requires you to look into your crystal ball and accurately predict the future.

But it’s not impossible. Armed with a good planning methodology you can

take a systematic approach to coming up with a realistic time estimate.

First determine the rough number of man hours needed to complete the

project.

METHOD #1: SCREEN ESTIMATION

One way to do this is to have a seasoned software developer look at all of the

screens and estimate on a screen by screen basis the amount of time it will

take to develop each screen. The complexity of each screen needs to be

taken into consideration as well as the business rules and what’s happening

in the database to make the screen function. Then additional time needs to

be allocated for subsystems and programming tasks that do not have screen

user interfaces.

“The lack of a test

plan is why so many

systems go live

loaded with bugs. “

“Go live plans are

particularly

important for sites

that have high

traffic, such as

ecommerce sites.”

Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

all of these individual estimates can go into

All of these individual estimates can go into a spreadsheet and be tabulated.

However beware of the pitfalls of estimating. Programmers are typically

optimists and tend to say things like “I can bang that out in 4 hours!” 16

hours later they’re still putting on the final touches. This happens for several

reasons:

The programmers can see the logic in their heads and thus it seems

straightforward and easy. It’s human nature to underestimate because,

as the saying goes, the devil’s in the details.

They don’t allow any time for testing.

They don’t allow time for integration & deployment.

They run into unexpected data or conditions that were not originally

identified and they haven’t added time for unknowns that are sure to

arise during development.

There should always be a value of at least 15% added to any best guess

project estimate to cover unknowns.

One way to get to a better estimate is to have 2 or more senior developers

independently define time estimates for the same list of programming tasks.

Then call them into a meeting together to compare notes. Now, as you can

image, this requires the developers to check their egos at the door and be

willing to accept constructive criticism. Estimating is subjective and based on

a programmer’s past experience so the numbers will vary somewhat.

However, you’ll find that many of the numbers will be surprisingly close. But

if one person says a particular screen will take 20 hours to develop and the

other person says it will take 200 hours then that means one of them is

wrong because of some false assumption they have about the system. A

healthy discussion of that screen will get to the bottom of the discrepancy

quickly and give you a much better estimate.

METHOD #2 FUNCTION POINT ANALYSIS

Another method of time estimation is the use of Function Point Analysis. This

is a technique for measuring software in terms of the functionality it delivers.

Each piece of functionality is identified and categorized. Complexity factors

are applied to each function point. In the end the equations produce a

number of man hours needed to complete the project.

Some companies will use the two different time estimate methodologies

mentioned above as a sanity check for one another. If the two methodologies

produce wildly different numbers then all of the assumptions about the

project should be scrutinized.

10. Schedule the Work

Size up your developerresources and create a schedule.Now armed with the

total number of man hours for the projectyou’ll be able to divide and conquer.

Set prioritiesin the project thendivide the differentscreens and tasks amongst

the team.Insettingprioritiesyou may want to ask the question“Whatis the

“Armed with good

planning

methodologies you

can take a

systematic approach

to creating realistic

time estimates.”

Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

minimum amount of functionality needed to bring

minimum amount of functionality needed to bring the application to market

or to go live?” This may cause you to divide the project into phases. If

possible, go live with a reduced-feature phase I so that the organization can

start reaping the benefits of the new system while phase II is being

developed.

Next map that to real calendar dates and don’t forget about holidays. Set

specific milestone dates during the life of the project so that you can

measure your success as you go. Remember, if you can’t measure it, you

can’t manage it!

So, how do you create a project schedule and capture the hundreds of

details? Some people try to do this with Microsoft Excel but Excel wasn’t

really designed for that purpose. It’s best to use an off-the-shelf tool like

Microsoft Project. However, pretty much any reputable project management

software package would suffice. Microsoft Project has been around for many

years, since 1984 actually. As you can probably imagine, it’s a very, very

mature product. It has features that make it easy for the novice as well as the

most seasoned project planner.

“The project schedule

merges the

time estimate with

the actual calendar

and resource

availability info.”

Example of a Software Project done in Microsoft Project

Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

planning a software development project

Planning a software development project can be a daunting process. But before

you start, you need to give some thought as to how you’re going to manage the

software development process. And like everything in life, there’s more than one

way to solve the problem. There are two primary schools of thought for doing

software development: Waterfall and Agile.

Waterfall is a process whereby the entire project is specified up front, then

written, then tested, bugs are fixed and then it’s deployed. This works great for

small projects but as the size and complexity of the project grows it becomes

increasingly difficult for the project stakeholders to understand the implications

of thousands of details. This is especially so if the spec writing process lasts for

months. As stakeholders dive deeper into the details they tend to change their

minds about things specified earlier. Change management in Waterfall is difficult.

Agile development methodology handles change better during the lifecycle of

the software project. It accomplishes this by breaking the project into smaller

“Waterfall defines the

entire project up front

whereas Agile breaks

the project into smaller

units where design and

implementation happen

in an iterative

process .”

“Choosing the right

development partner

will ensure success in

your project.”

units and having an

iterative process that

engages the

stakeholders early and

often. Design flaws are

discovered earlier.

Feedback goes

immediately to the

developer and is put

into the next iteration.

All of the same design

work that is done in

Waterfall still needs to

Analysis &

Design

Implimentation

Initial

Planning

Deploy

Evaluation

& Feedback

Testing

be done in Agile, it’s just done in more manageable, bite size chunks. Since the

cycle time is shorter problems can be addressed while the design details are still

fresh in everyone’s mind. With Waterfall there may be months between design of

a given screen and its actual implementation. So it’s hard to remember all of the

reasoning behind the original design. For more on Agile Development see:

http://en.wikipedia.org/wiki/Agile_software_development

Conclusion

The number one reason for software project failure is poor planning. Following a

process, weather Waterfall or Agile, forces you and your staff to completely think

through everything that’s going to be built. Errors in architecture are significantly

less expensive to fix earlier in the project so proper planning is crucial.

What would happen if a high-rise building were constructed without fully

designing the first floor? The project would be a disaster. The construction

industry ensures quality and building safety by a very detailed process of project

planning. Should we expect anything less from our mission critical software

development projects? Working with seasoned software project planning experts

will give you an edge and choosing the right development partner will ensure

success in your project.

Keene Systems, Inc. One Bridge St., Suite 5, Plymouth, NH www.KeeneSystems.com 603-726-5058

discipline is the bridge between goals

“Discipline is the

bridge between

goals and

accomplishment”

SMARTER

DEVELOPMENT

Experience &

Discipline

We have developed

software for some of

the most prestigious

companies in the

world:

National Geographic

IBM

EDS

Mack Trucks

Texas Instruments

NSTAR Electric & Gas

Kimberly Clark

Monsanto Agricultural

Harris Corporation

BAE Systems

Elizabeth Arden

Mary Kay Cosmetics

Calvin Klein Cosmetics

Ralston Foods

Sara Lee Bakery

Hershey Canada

Cadbury Beverages

Hormel Foods Corporation

Perdue Farms

J.M. Smucker Company

Ocean Spray Cranberries

Tootsie Rolls Industries

Uncle Ben's

McCormick & Company

Lindor Chocolate

Butterball Turkey

Birds Eye Vegetables

Reynolds Aluminum

Pontiac Foods (Kroger)

Dartmouth-Hitchcock

Medical Center

Dana Farber Cancer

Institute

Partner's Healthcare

Caritas Christi Health Care

Janssen Pharmaceutica

Lonza Biologics

Pfizer Animal Health

GlaxoWellcome (UK)

Bayer Corporation

Ciba Self Medication

Mohawk Fine Papers

Haley & Aldrich

Prestone Products

State Street Research

Informa Global Markets

Kamakura Corporation

Homesite Insurance

Mass. Division of Insurance

Mass. Board of Medicine

Proper software development requires discipline

and good planning brings order to the chaos.

Call me today for a FREE IT Consultation

(603) 726-5058 (my direct line)

I will personally walk you through our

proven process for making your ASP.NET

Software project a success, delivering it

on time and on budget.

Don't risk failure. Call today.

Lance Keene

President

Keene Systems, Inc.

603-726-5058

Lance@KeeneSystems.com

What clients have to say about Keene Systems

“Keene Systems developed a

profitable e-commerce site and

two powerful intranet

applications for us. One was an

editorial application for

entering new books and

updating the live site through a

work flow-controlled process

that included editor, publisher

and author approvals. The

second was for customer

service, billing, and financial

reporting and detailed activity

monitoring. In all three cases,

Keene Systems delivered

outstanding turnkey systems

that were flexible and open-

ended.”

David Wilcox,

CEO, MeansBusiness, Inc.

“Keene Systems enabled us to

create an internal database-

driven HR application that

calculated employee bonuses

and hid its complexity from

our users. Although web

based, the UI was as simple to

use as a spreadsheet.”

Nancy Spalding-Gray

IT Manager

State Street Research

project on schedule and on

budget.”

Sharon Hershon

IT Manager

Partners Healthcare

“The Bariatric database has

proven to be a successful tool

for our program. It is very

smooth for all staff to navigate

patient information, follow

patient meeting attendance, as

well as track patient weight

loss. We will gladly work with

Keene Systems in the future, as

our needs change.”

Shari Plourde

Bariatric Coordinator

Dartmouth Hitchcock

Medical Center

(Now BlackRock, Inc. a prominent

Investment Management Firm)

“To help us create an internal

patient record-keeping system,

Keene Systems provided the

responsive service we needed,

delivering the completed