Keene Systems latest whitepaper release simplifies the process of planning a software project by comparing it with the phases of building a house. To simplify it even further, Keene also developed a clever infographic that visually walks the viewer through the 10 step process with a conversation between a construction worker and a programmer.

1. Keene Systems latest whitepaper release
simplifies the process of planning a software
project by comparing it with the phases of
building a house. To simplify it even further,
Keene also developed a clever infographic
that visually walks the viewer through the 10
step process with a conversation between a
construction worker and a programmer.

2. Here's how to plan a
software project that
will succeed:
State the Goals. As in any
endeavor in life, whether
building an enterprise software
solution or building a house, the
first step is always defining 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?”

3. Identify
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 and
thus 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.

4. Identify Processes & Dataflow. 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 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 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 origination but others will
require process reengineering in the context of the new capabilities made possible by the
new software system.
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.

5. 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.

6. Screen Mockups. 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 tas
that their job dictates. To properly plan a software project *all* screens in the system must be identified.
FACT: A common reason for software project failure or cost overrun is because not all of the screens were identified and designed in the planning stage.
The screen mockups have the extra added benefit of involving the system stakeholders and future system users early on in the process. Often users
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 wan
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.

7. Integration Plan. 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 need to be identified; not only wha
data is to be transferred but also an explanation of how and when it is to be transferred.
Sometimes the method of communication between two systems is a big unknown and requires a proof-of-concept prototype of passing data just to
discover what is possible during the planning stage. 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.

8. Test Plan. Lack of test plans 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’s 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 are 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 acceptance.

9. Go Live Plan. 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.

10. 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 systematic approach to coming up with a realistic
time estimate.
First determine the rough number of man hours needed to complete the project.

11. Schedule. Size up your developer resources and create a schedule. Now armed with the total number of man hours for the project you’ll
be able to divide and conquer. Set priorities in the project then divide the different screens and tasks amongst the team. In setting
priorities you may want to ask the question “What is the 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. 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.

12. Download How To Plan A Software Project Whitepaper
Brought to you by:
Keene Systems, Inc.
10 Panaway Dr. Campton, NH 03223
603-726-5058
www.keenesystems.com
sales@keenesystems.com
Infographics by:
www.SparkEvolution.com
603-651-7929