Projects -
Successful projects that are on time and on budget do not happen by magic.
It takes an ongoing effort by all team members to make sure that things stay on
track and that any problems are identified and handled as early as possible.
Some things to consider:
Project Costs:
Custom projects can typically be handled in one of two ways, either on
a per hour cost or on a per project basis.
In order to define a per project cost, the specifications for a project must be
fairly complete and detailed. In the event that a project is not thoroughly
defined, it may be necessary to split the project out into 2 projects. The
first part wouild be to better define the project and the second would be the project
itself.
Typically, projects are billed out on a per hour basis. It's still worthwhile
to have a firm handle on what your overall budget is and what the expected costs
might be. Depending on the nature of the project and what's agreed to, not
all hours would be billable. In our case we may make allowances in those
instances where we may
not be up to speed in certain technologies that we may be able to reuse on future
projects.
When computing the cost of the project don't forget the time of your staff to work
with developers from defining specifications to approving screens, answering questions,
running tests along the way as well as final testing.
Back to Top
Defining the Audience:
A very large part of the project cost is related to time. The longer
it takes to develop an application, the greater the expense.
Although there are those developers whould would argue that there's only one correct
way to build an application, the scope of the project and the associated cost typically
is better defined by the target audience and the need that is being filled.
A non-critical application that is intended for a limited number of internal users
to fill a short term need is considerably diffferent that one that is core
to the business, used by your customers 24/7 with full expectations of reliability
and security.
Over the years we've had projects that one of our clients termed "Q&D" - quick
and dirty. These are applications, which are usually internal, where the expense
needed to develop that application needs to be contained or other projects may have
a higher priority and the client is willing to live with the occasional error and
does not need every aspect of an operation automated as long as they can get something
that works in the short term. Those steps of a process
which are rarely used are not programmed. Help screens may not be necessary and
error logging might be kept to a minimum. As developers we might fall back
to less object oriented
techniques. Typically these applications work fine and
any limitations are not severe. The only drawback is that some of these Q&D
applications live longer than originally expected and might require additional maintenance
expense over that longer lifespan.
If the application is destined to be available to a larger audience then a layered,
better thought through
design seperating out the presentation, business and data layers working around
a core group of classes is a much better approach. Of the total time spent
on a project, in many cases as much as 40% could be spent on initial design.
The expectation is that a solid design will typically generate a better end product
with much less maintenance and will provide a solid foundation to add future features.
It's also very possible that programming objects created during the initial project
can not only be reused for the original project but can also be reused for future
applications.
Sometimes, very infrequently used options within a planned application might take
a disproportionate amount of time to develop. When defining a project make
sure to think through all the scenarios that the application wil need to handle.
You may then want to assign how often each scenario would occur and if that scenario
was not handled by the application what the external effort might be. This
scenario might be something that can be deferred until a subsequent release of
the application.
Back to Top
Deliverables:
Ideally the specifications for a project should be spelled out clearly
and completely before the project begins. However, in most cases those specifications
might not be as detailed as they should be and the project will need to be fleshed
out. We can work with you on getting those specifications defined, better
allowing us to provide a more accurate estimate as to the time and cost of the project.
In many cases having a complete set of product specifications and more importantly,
making sure that they are updated as changes are approved, is a much better alternative
to writing internal and user documentation after the project is complete.
Once a project is approved, define what should be deliverable during the course
of the project. These should include not only those elements that are part
of the final implementation but those components that should be created along the
way. These might include completed specifications, mock-ups of screen designs,
database layouts, interfaces with existing systems, etc. They should also
include a list of milestones, steps along the way to completing the project, that
can be measured so that adjustments can be made along the way.
Another deliverable which sometimes is not considered is insuring that along with
a production system a test system is also made available that can be used for developing
new features and could possibly be used for training.
Back to Top
Maximizing Success:
It's rare for a project not to have a few unplanned expenses along the
way as new features might need to be added or mystery problems surface. Then
again there are those projects, when not closely monitored can get more expensive
by the day, and possibly fail.
Some recommendations to follow:
Expect to be involved with the project from day one. That doesn't
mean that formal daily meetings need to be scheduled but it is important
to establish on ongoing communication
with the project developers. Also make sure that the internal staff is available
to do any intermediatary testing as the progress moves through various checkpoints.
as well as working through the final set of testing prior to implementation.
Stay focused. Changes are inevitable during the course of
a project, but make sure that those changes do not interrupt the overall flow of
the project. In other words, adding a new field to a customer record might
have a relatively small impact on the project's timeline. Add a completely
new set of logic that was never originally considered, might cause work that has
already been done to be re-done which may cause other changes to cascade.
If this a new application it might make the most sense to keep the feature list
as simple as possible for the first release, but it's always a good idea to keep
the longer term in mind to insure that the foundation for the application is solid
enough to manage future improvements with subsequent releases. Once the first
release is out the door and in production, it's easier to see what has worked and
what hasn't.
Maintain momentum. The worse thing that can happen to a project
is that it goes through a period of start and stop development. This could
be caused when approvals are delayed, resources become unavailable, priorities change
or any number
of reasons. These constant
restarts lead to wasted time and can cause
inconsistencies in the code requiring higher maintenance costs along the way.
Stay vigilant in having the code maintained. It's important
that after the application is accepted and in use, that there is a system in place
to report all encountered problems. If the application reaches out directly
to your customer base make sure that the are always ways and difficulties can be
easily reported.
Be realistic. Project specs invariably change during the
course of the project. Unexpected problems are encountered. Resources
might not be available. It's best to step back, re-estimate and decide on
what changes to the schedule need to be made throught the project lifetime - and
that doesn't mean dumping a bunch more developers on a project in the late innings
(something which doesn't have a very good track record of ever working).
Back to Top