Posted on

9 Steps to a Hassle Free and Effective Software Development Project

Has your company developed entirely new software or added to software already in use throughout the organization and found the process cumbersome, frustrating, and sometimes not living up to expectations or meeting organizational goals?  If so, the solution to a smooth and effective development program may be as easy as staffing a well-qualified project manager and adopting a proven development process.

For any software development or other project initiative your company may be considering, it is critical to have in place and practice a set of effective and proven guidelines to ensure project success and delivery of the expected results: taking into consideration the role and responsibilities of a well-qualified project manager, knowledge of important business and financial aspects, and a step-by-step process that all contribute to the solid foundation and implementation of an effective project plan.
 

 

Developing a Practical Approach: The Role of the Project Manager

When undertaking a software development project, the first element to consider is the establishment of a comprehensive yet practical approach to the initiative that ultimately will lead to a successful end result.

The in-house project manager has a key role in ensuring each phase of the project is carried out as planned. The project manager is responsible for considering the potential risks involved with the project and how to avoid and resolve them, establishing and maintaining momentum throughout the project, ensuring individual project team member tasks are assigned appropriately and carried out according to specifications, and successfully addressing and resolving any conflicts that may arise during the length of the development project.

A well-qualified project manager is able to address what may seem to be an overwhelmingly complex process by developing an organized approach where the process is broken down into manageable individual tasks and understanding how to keep those involved in the project dedicated to the ultimate goal of meeting and even exceeding the expected end result.

Embarking on the Initiative: Key Steps to Consider

With a comprehensive approach and a competent project manager in place to guide the new software development initiative, there is another important element your organization may find helpful as you embark on the project: establishing specific steps that can be followed to project completion that are based on proven industry experience in such a project environment.

Two renowned experts, Dr. Gordon Scott Gehrs and Dr. Dorota Huizinga, single out nine key steps to consider as you embark on a software development project:

Step #1: Conduct Feasibility Analysis


Step #2: Analyze and Determine Requirements
Step #3: Consider Industry Best Practices
Step #4: Design
Step #5: Measuring and Tracking Progress
Step #6: Development
Step #7: Addressing Automation
Step #8: Testing
Step #9:  Gradual Implementation Practices
 

 

Full article, presenting in detail these key practical guidelines to approach a software development project, is available at: http://www.executivebrief.com/article/9-steps-to-a-hassle-free-and-effective-software-development-project/

 

By ExecutiveBrief: http://www.executivebrief.com

 

Posted on

A Few Reasons Why Project Changes Occur

Some of the most common reasons why change requests are made.

Change requests alter the course of a project and working within the constraints of time, budget and quality more challenging. If change requests are not handled properly, the project will overshoot its schedule and accumulate costs that are beyond the original plan.

Realize that change requests are not made because people in your team, the project sponsors, or clients cannot make up their minds. Instead, most requests for changes are made in order to improve the project and, in some cases, the process of implementing the project.

Changes are inevitable during the course of the development lifecycle, and there are various reasons why changes occur. Some of these reasons are technical, some are procedural, some are financial, and still some are political or people-related.  Whether a project manager supports the adjustments or not, it is important to think over why changes are requested and their possible impact on the integrity of the project, as well a the delivery process. Let us look at the most common reasons why changes occur.

Incomplete requirements

Scope changes –or creeping functionality–are the results of ineffective management of requirements.  These are also the results of a project manger’s inability to get approval from project sponsors. When requirements kept going through changes during the course of a development lifecycle, new features and functionalities are often added, resulting in a product that overshoots the allocated time and resources, but fails to meet an acceptable level of quality.

Organizational restructuring

If the client’s organizational structure changes midway through the project lifecycle, it is inevitable for the delivery team to expect either a closer scrutiny of the project or change requests to be submitted. Financial considerations, corporate policies, and new sets of end users are some of the factors to consider as change agents when organization restructurings happen. Some requirements are too rigid, while some requirements need more room for discrepancy in specifications.  When alpha releases prove to be too limited to one set of target users alone, then expect change requests from auxiliary end-users.

External factors, such as new vendors, technologies, or methodologies

External factors, such as the involvement of another vendor or a representative end-user, can cause diversion from the original project execution plan. This issue is often as technical as it is financial (or political). Ideas that are tied to the new vendor’s methodologies and technologies can affect the execution of the project plan halfway through the lifecycle.  Sometimes, clients can be finicky about what they want out of the project that agreed-upon requirements kept getting changed. The more a finicky client gets in contact with vendors who want to take on the project, the more ideas they get about “improving” the product and cutting the cost of development. In such a scenario, be prepared.

By ExecutiveBrief: www.executivebrief.com

 

 

 

�

Posted on

Fix Your Bugs!

The early World War I fighter planes had machine guns mounted above the fuselage.  They fired right through the spinning propeller.  That worked most of the time, but occasionally cut the propeller right in two!  I’d call that a bug.

I’ve learned over the years to fix my bugs quickly.  As soon as they are discovered.  Leaving unfixed bugs in a product can result in some nasty consequences.

Suppose you’ve got a small bug that bothers a few smaller customers.  It may not cost you anything in lost sales.  Most people can live with it.  But then along comes a big demanding customer.  When he sees it, maybe along with a few others, he freaks out and decides not to purchase.  You just lost a great sale because of one little bug.  A bug you could have easily fixed.

Moral of the story: don’t cut your propeller in half.

–ray

Posted on

Features Don’t Make Money, and Yet They Do

In my line of business, we often get customers who say, “If your product only had this great feature [that I need] it would really sell.  You’d make a million dollars!”

Such enthusiasm prompts us to run off and produce the requested feature as soon as possible.  And when we do…  Nothing happens.  Nobody’s there to heap praise on us and pay the big bucks.  The product doesn’t sell any better than before, and no such millions are made.  It begs the question: do new features make money?

Certainly from a short-sighted standpoint, the answer is no.  There are no crowds of new customers clamoring for the new feature.  In fact, most evaluators simply take the new additions for granted, and only stop to comment when something they want is missing.  No praise is given for products with great new features.  But lots of crap is shoveled out when something isn’t there.  That’s just normal human nature.

But over the long term, a constant flow of new features that solve customer problems is a good thing.  It builds your customer base and takes the heat off sales and support staff.  View it as a long-term investment that will eventually pay.

 

— newshirt

Posted on

Define: Make Verses Buy

Make verses buy: The act of building a product for your own internal use as opposed to licensing a pre-existing product.

 

Organizations with the ability to produce their own products are often tempted to build everything, including the tools they use.  This is most common with software companies.  They have a bank of software developers, some sitting idle awaiting jobs, and the company is tempted to use those resources to build all the tools they use.

I once worked for a software company that wrote their own compilers and debuggers.  For internal use only.  Yikes!  When Microsoft sells compilers for less than a thousand bucks, this doesn’t sound cost effective to me.

Again, the temptation usually stems from developers sitting around on their hands with nothing to do.  Why not put them to work building internal tools?  My opinion: bad idea – almost every time.  Those developers are saving the company very, very little money.  After all, off-the-shelf software is cheap.  So, divide the number of hours they work by the cost of the software, and your developers are only making a dollar an hour.  Better to put them to work in customer support or sales, cold calling for gigs.

The real killer comes when the software they wrote needs bug fixes and maintenance.  Are those same developers still available?  Usually not.  So who pays for the bug fixes?  You.  Was it still cheaper to write your own stuff?  I doubt it…

 

–newshirt

Posted on

Advice: Develop Products for the 98%

Here’s some project management advice: And I’m going to complain a bit…  Hope you don’t mind.  🙂  I notice user interface design – especially in software products.  I notice menu placements, dialog box layout, screen widgets, and everything else.  And there’s one thing that always bothers me.

    Complex products seemingly designed for 2% of the intended users – %*^$*#

Developers fall into a common trap: adding too many menus and screen gadgets.  Here’s how it happens…  Sales managers, product managers, and CEO’s all want products to do something new.  Something big and flashy.  Something they can sell.  So, they call down to the developer’s cubes to make it happen.  And it does!  Unfortunately, so do dozens of other feature requests.

Developers often don’t know how to bury the obscure features and highlight the common stuff.  Everything is given equal weighting in the user interface.  That’s okay until you have a hundred big features.  And then everything runs together.  Users see so much stuff, they can no longer gear the product to their own purposes.  It takes a Masters degree to figure it all out.

A better approach is to develop the product for the 98% of customers who will use it.  In other words, MAKE IT SIMPLE!  Bury the features intended for the other 2%.  That doesn’t mean you’ll only bury 2% of the menus and dialogs because normally about 50% of the product falls into the “obscure” category.  Bury all that, and explain it to the 2% who need it.

 

–ray

Posted on

Scrum Burn-Down

Have you ever used a scrum burn-down chart?  Funky name, huh?  It’s actually a pretty handy line chart.  The image below is an example from Standard Time®.  There, it’s called a project history chart. On the X axis, you see time (weeks, months, quarters).  On the Y axis (vertical) you see the number of remaining hours for your project.  As work is applied to the project, it burns remaining hours down to zero.  Team members can see the downward trend and predict when the project will finish.  This is the “light at the end of the tunnel” chart that helps people push for completion.  Show this in your scrum sprint meetings, and your team members will take heart.   Scrum Burn-Down Chart  As you can see, there are some up-ticks as well.  Those represent project scope changes.  Some bright individual decided the project needed a slowdown, and added some additional tasks.  Do that at your own peril, because this chart shows all. –ray

Posted on

Advice: Have a Project Champion

Project management advice: Every project needs a champion.

It took me a while to understand the nature of product development and the need for project champions.  At the beginning of my career, I believed projects just “got developed.”  I was working in a research department at Eastman Kodak Company, building cutting edge photocopiers.  Engineers buzzed around, building microprocessor-based circuits, image-enhancing emulsion, and writing software.  I did my part and just expected the product to come together.  Looking back, I now realize there was one man who made it all happen: a gray-bearded old dude who wanted to change the industry.

Products get developed, and projects finished, only when there is someone with the burning desire to see it happen – like the old bearded dude in the example above.  A paycheck is not enough.  You have to want it badly.  Only then will you fight through all the obstacles to make it happen.  Projects often take 2-3 times their original estimates, and some required several iterations to realize the full glory.  And only a true champion will endure the suffering to see it to completion.

Look around at your project.  Do you have a champion?  A person who refuses to give up?  If not, you have good reason to fear that the project could be canceled or back-burnered.  Have you personally ever been a project champion?  If not, give it a try.  Throw yourself into something that really engages your passions.  You’ll find there’s satisfaction in a job well done.

 

–newshirt

Posted on

Define: Feature Creep

Feature Creep: Small product feature additions that unexpentantly expand a project scope.

 

Feature creep is one of the big reasons projects ship late.  Some people simply cannot deny themselves.  They want more and more features in their great new product, and can’t stop adding them  Here’s how it happens.

When a new product feature is complete, there are oohs and aahs from all the project stakeholders.  They love it!  Why?  Because they are sure customers will find it useful and reward the company with more business.  That’s only natural.  But then something else happens…  One of the stakeholders steps up and says, “That’s cool, but can it do one more little thing?”

All the other stakeholders agree.  The new feature you added is nice, but the product should do one more thing to be complete.  And they may be right.  So you add that.  And a few more things.  And a few more things after that.  That’s feature creep.

Little additions creep into your product features until they consume a major part of the project timeframe.  The extra features are nice, but can you afford the extra time?  After all, you now have less time to implement all the other cool features you were asked to do.

Stakeholders often don’t understand this problem.  Later, they’ll come around and ask why your project is behind schedule.  You can’t say that it’s because of all the little things they asked for.  Why?  Because they won’t remember those or they don’t see them as a major time sink.  See the problem?  You can’t win with feature creep.  🙁

 

–ray

Posted on

Build vs. Buy

Every company needs specialty tools to make their company run – little things to help make things easier.  For example, a cabinet shop might need custom-built jigs.  An auto mechanic may build a few of his own tools for jobs he performs frequently.  High-tech companies certainly build plenty of in-house programs to manage information technology – databases, data entry, customer records, etc.

The question I’m posing is this: when is it right to build those custom tools in-house, or when should you go out and buy a suitable tool instead?  For instance, should an auto mechanic build his own 500 piece wrench set, or go down to Sears and buy them?  Should a tech company build a time tracking product from scratch, or license something like Standard Time®?

Since I’ve personally worked in consulting for a number of years (in another life), I’ve seen it all.  I’ve seen companies build products that were available off-the-shelf for 1/100th of the cost.  And, I’ve seen people shoehorn freeware code and products into commercial use.  Both were mistakes.

I tend to say that companies should only build products that are much more expensive to buy.  In other words, don’t try to write your own compiler – Microsoft does that just fine.  Another reason to build is when you have exotic business needs.  One last reason might be if you have time on your hands.  If you’re not making money serving customers, maybe you’ll have time to write and maintain a few necessary tools.  But that’s a dangerous position to be in.

In IT, we ignore such advice because we know we can build everything.  But I suppose the mechanic with a little metal-working and welding experience does the same thing.  🙂

What tools have you built, and regretted it?  Post a comment and let me know!

 

–ray