Eccountable

Eccountable
  Menu navigation requires JavaScript.  
`

Products

[ go ]

Consulting

[ go ]

Vertical Markets

[ go ]

Managed Services

[ go ]

When was the last time you paid to have something built? If that project was going to be your personal home, would you hire carpenters to just start hammering away without blueprints? Do you think the carpenters could give you a reasonable estimate on how long it would take to build or how much it would cost? Probably not.

If you are building information technology (IT) systems, don't hire a programmer to write code unless you have a plan on how you will manage risks, and set goals.

If you want a guarantee of a project that is completed on time and on budget, you will need to pay someone (preferably eccountable) to spend the time understanding your business and draw up the "blueprint", or in IT terminology, a requirements and specifications document. And you should expect to get a team of people that specialize in the various tasks, including project management, which will make your project meet your schedule. Contact eccountable now to get started!

Do you need requirements and specifications to successfully complete any project? Not necessarily. There are many ways to attack that problem and each has its pros and cons.

Methodology

Pros

Cons

System Development Life Cycle, (SDLC) aka the "Waterfall" approach
  • Using a requirements and specification document, you can estimate budget and timeline
  • Good for outsourced projects
  • Requirements and Specs protect clients and developers from misunderstandings (risk reduction)
  • The lowest cost for projects involving more than a few people
  • Not flexible for rapidly changing business environment
  • Takes a while to see beta system
  • You need a team approach, not just programmers
  • Serial sequence of project steps
  • Risk factor: Poor design may not yield what users need

 

Rapid Application Design (RAD)
  • Short turnaround for small projects
  • Very flexible
  • Works well with established development environment
  • You can use ROI of one deliverable to fund future development
  • May require expensive software tools, and /or specialized programmers
  • Not inexpensive
  • Software is usually not complex or scaleable
  • Documentation and software quality will suffer

Spiral Model (hybrid of SDLC and RAD)
  • Gets users more directly involved and are more likely to adopt the system
  • Risks are explicitly assessed and resolved throughout the process
  • ROI Funding of each successive step (see RAD)
  • Having a written requirements document will help control incremental development cost

  • Direction of project may change depending on feedback users give during development
  • You still cannot estimate total project size and cost

eXtreme Programming (XP)
  • Good for risky projects with dynamic requirements
  • Code must have unit tests
  • Frequent, small feature releases every 1 to 3 weeks
  • High quality code
  • Programmers must have domain knowledge
  • It takes two or more programmers
  • Customer must always be available
  • System may be sub-optimal

 

Here are some of the tools eccountable uses to develop software:

Programming Toolbox

And here are some related links to managing software development projects:

Big Bang, Large Crater

Big bang installations utilize the big red switch methodology, where a transition just requires throwing a big red switch, and then a miracle happens. Miracles seldom happen in the software industry, and going for a big bang often leaves you with nothing more than a large crater. (Jan. 2005 StickyMinds)

Opening the book on ITIL

About 20 years ago the British Government created the IT Infrastructure Library (ITIL), a set of seven best-practice IT management books. It has been big in England and the Netherlands for the past 10 years, and is spreading in America and Australia. (May 2004 Sydney Morning Herald)

The Tyranny of On-time and On-budget

IT project management grew out of construction project management and large-scale engineering design projects: large, complex undertakings with lots of moving parts and lots of dependencies. Conventional wisdom claims that something like 50-70% of all IT projects fail. Other than as a way to either beat up on IT management or to sell project management services by systems integrators, is there any important insight buried in this data? Increasingly, I think not. (Feb. 2005 Enterprise Systems)

Why Software Fails

Have you heard the one about the disappearing warehouse? One day, it vanished - not from physical view, but from the watchful eyes of a well-known retailer's automated distribution system. A software glitch ...


Driven by Farcry Open Source CMS. Dressed in Aura.
Powered by ColdFusion MX.