Basic Steps to setup a contribution in osCommerce

A few steps to install a contrubution in osCommerce:

- If it is for front end dispaly then paste its respective files catalog folder like in includes/language/english will contain its english text file

- Change in filenames.php
- Change in database_tables.php
- We may also need to add files/folders over like for shipping related module we would need to add it inside "catalog\includes\modules"
- Rest any other informatio is provided inside the zip of that contribution



- Similarly for admin related contribution

Open Source Video Tutorials

http://php.opensourcecms.com/free/videos.php

Few good Joomla Components

Joomla Some good Plugins

Menus - swMenu

Events : redEvent

Newsletter: ccNewsletter

Photo Gallery: expose4

Video Gallery: expose4

URL Rewrite - sh404

Appointments - Appointmentbookingpro

Forms - Breezing forms

Tickets - RSTickets

osCommerce Plugins

for photogallery :photo_gallery09.zip

for contact us page : Add Store Details To Contact Us_1.zip

for shipping : Additional Shipping Options for Zone Module.zip

for article : article_manager_v1.0.zip

for customer testimonial : Customer Testimonials v5.zip

fckeditor : fck_autoinstaller_2.14_2.zip

for multimage of products : Simple Multiple Images (Unlimited) with Fancy Popups V1.25.zip

for order tracking : orders_tracker.zip

for shipping : UPS-USPS-FEDEX.zip

Help&FAQ.zip

Joomla! 1.5 with JomSocial, JomComments, myBlog or similar are hard to beat if you're looking for a facebook-like appeal, in my .02. but, I'm a tad bias ;)

What is the difference between JScript, Javascript and jQuery?

JavaScript is the common term for a combination of the ECMAScript programming language plus some means for accessing a web browser's windows and the document object model (DOM).

JScript is Microsoft's version of JavaScript. The programming language itself is very similar to ECMAScript, but the DOM access differs in many respects.

JQuery is a JavaScript library that handles many commonly used features and also handles the differences between, e.g., Internet Explorer and standards-compliant browsers. It's something you can use to reduce the amount of work when creating web-based applications.

23 Ways to Keep Clients for Life

23 Ways to Keep Your Customers for Life

Written by Arnold Sanow, MBA, CSP (Certified Speaking Pro). Arnold Sanow, is a nationally renowned business, communications and people skills expert and author who speaks professionally. He works with his clients to provide them with the tools, techniques and solutions to improve and maximize individual and organizational performance. I loved this document and I want to share it with you. I have put my comments or stories in green type.

Today's fast-changing and competitive environment, excellent customer service is essential for success. The strategies for keeping customers for life can be honed down to some basic steps that any business owner can use. To get customers, keep them and to get enthusiastic referrals follow these 23 proven techniques:

1. Reward your customers. Send them a gift, provide them a lead, generate business for them, etc.

2. Use your customers' services and buy their products. If you want to increase loyalty, there is no better way.

3. Send thank-you cards. Make sure they are handwritten and sent promptly. Peter Drucker attributed much of his success to the fact that he sent out 12 thank-you cards every day.

4. Return phone calls promptly. Since so many people don't return calls, you automatically look good when you do.

5. Do what you say you are going to do. This builds trust quickly.

6. Do things when you say you're going to do them.

7. Under-promise and over-deliver. (This one is huge!)

8. Be accessible. Make sure you are available and willing to help customers whenever there is a problem. Your business should be open to meet the convenience of your customers and not only for your convenience. (That’s why I have a 3 Hour Call Back Guarantee 7 days a week!)

9. Be credible. If you can't establish that trust right away, customers may start to look at your competitors. (You must have professional expertise)

10. Appearance counts. Perception is reality, and the reality is that people do judge a book by its cover. (I will never forget this story that happened a few years ago in the Silicon Valley—a couple who had lost their very high paying jobs in the tech sector after 9/11 were forced to sell their $2.5 million home and one listing agent showed up for his listing appointment in shorts and polo shirt after a round of golf. Needless to say, he did not get the listing.)

11. Show empathy. Remember the best customers are your currents ones. Stay in touch and continue to service their wants and needs.

12. Have a "Goof Kit." If you make a mistake, it's not enough to say, "I'm sorry." Make the situation right. (A couple months ago we ran into problems that delayed a closing by 2 days and the buyers now needed to be out of their current apartment on the new day we were closing. This is what I did—I volunteered to rent a U-Haul truck for them so that they could begin moving their belongings into the truck in advance of closing.)

13. Promote customers' products and services. By getting business for your clients, you ensure you will have a customer for life.

14. Do things for the customer's convenience not yours. Make it as easy as possible for your customers to do business with you. The easier you can make it for your customer to do business with you, the more business you will have. Determine all the ways you can eliminate the hassle factor.

15. Send an invoice periodically with a "no charge" on it. This will help your customers remember you. And if it is unexpected, it will have a much larger impact.

16. Have a customer advisory panel. Only by knowing your customers' wants and needs can you successfully grow your business and be totally customer-oriented. (I love this idea!)

17. Hire mystery shoppers. To really find out how good your customer service is, hire someone to go out and use your service from start to finish.

18. Be a resource. No matter what your customer needs, try to find it for them -- even if it has nothing to do with your business.

19. Speak your customers' language. If you use jargon your customers can't understand, they won't use you.

20. Treat your employees well. If they are treated poorly, there is a good chance your customers will also get poor service.

21. Give your customer what they want, when they want it and how they want it.

22. Give back to your best customers. If you run a special price or product offer for first-time customers, ensure your current customers are offered the same opportunity.
23. Don't show an attitude of indifference to your customers. In a recent study on why people give up on a company, 68 percent quit because of an attitude of indifference toward the customers by the owner, manager or employees - 68 percent!

Conclusion
"Customer service is more than just smile training -- it's about treating people the way they wanted to be treated," "It's also about giving the client what they want, when they want it and how they want it. It really comes down to the fact that good communication and human relations skills equals good customer relations."

Query to get duplicate records

select count(*) as num, a, b from a group by b,a having count(*) > 1

Use Firefox to spell check your website

Paste give below code in your addressbar after opening a web page.

javascript:document.body.contentEditable='true'; document.designMode='on'; void 0

10 best practices for successful project management

The right mix of planning, monitoring and controlling can make the difference in completing a project on time, on budget, and with high quality results. Here are some guidelines to help.

Given the high rate of project failures, you might think that companies would be happy to just have their project finish with some degree of success.

But that's not the case. Despite the odds, organizations expect projects to be completed faster, cheaper, and better. The only way that these objectives can be met is through the use of effective project management processes and techniques.

This list outlines the major phases of managing a project and discusses key steps for each one.

PLANNING
1: Plan the work by utilizing a project definition document
There is a tendency for IT infrastructure projects to shortchange the planning process, with an emphasis on jumping right in and beginning the work. This is a mistake.

The time spent properly planning the project will result in reduced cost and duration and increased quality over the life of the project. The project definition is the primary deliverable from the planning process and describes all aspects of the project at a high level. Once approved by the customer and relevant stakeholders, it becomes the basis for the work to be performed.

For example, in planning an Exchange migration, the project definition should include the following:

• Project overview: Why is the Exchange migration taking place? What are the business drivers? What are the business benefits?
• Objectives: What will be accomplished by the migration? What do you hope to achieve?
• Scope: What features of Exchange will be implemented? Which departments will be converted? What is specifically out of scope?
• Assumptions and risks: What events are you taking for granted (assumptions), and what events are you concerned about? Will the right hardware and infrastructure be in place? Do you have enough storage and network capacity?
• Approach: How will the migration project unfold and proceed?
• Organization: Show the significant roles on the project. Identifying the project manager is easy, but who is the sponsor? It might be the CIO for a project like this. Who is on the project team? Are any of the stakeholders represented?
• Signature page: Ask the sponsor and key stakeholders to approve this document, signifying that they agree on what is planned.
• Initial effort, cost, and duration estimates: These should start as best-guess estimates and then be revised, if necessary, when the workplan is completed.

PROJECT WORKPLAN
2: Create a planning horizon
After the project definition has been prepared, the workplan can be created. The workplan provides the step-by-step instructions for constructing project deliverables and managing the project.

You should use a prior workplan from a similar project as a model, if one exists. If not, build one the old-fashioned way by utilizing a work-breakdown structure and network diagram.

Create a detailed workplan, including assigning resources and estimating the work as far out as you feel comfortable. This is your planning horizon. Past the planning horizon, lay out the project at a higher level, reflecting the increased level of uncertainty.

The planning horizon will move forward as the project progresses. High-level activities that were initially vague need to be defined in more detail as their timeframe gets closer.

PROJECT MANAGEMENT PROCEDURES
3: Define project management procedures up front
The project management procedures outline the resources that will be used to manage the project. This will include sections on how the team will manage issues, scope change, risk, quality, communication, and so on.

It is important to be able to manage the project rigorously and proactively and to ensure that the project team and all stakeholders have a common understanding of how the project will be managed. If common procedures have already been established for your organization, utilize them on your project.

4: Manage the workplan and monitor the schedule and budget
Once the project has been planned sufficiently, execution of the work can begin. In theory, since you already have agreement on your project definition and since your workplan and project management procedures are in place, the only challenge is to execute your plans and processes correctly.

Of course, no project ever proceeds entirely as it was estimated and planned. The challenge is having the rigor and discipline needed to apply your project management skills correctly and proactively.

• Review the workplan on a regular basis to determine how you are progressing in terms of schedule and budget. If your project is small, this may need to be weekly. For larger projects, the frequency might be every two weeks.
• Identify activities that have been completed during the previous time period and update the workplan to show they are finished. Determine whether there are any other activities that should be completed but have not been. After the workplan has been updated, determine whether the project will be completed within the original effort, cost, and duration. If not, determine the critical path and look for ways to accelerate these activities to get you back on track.
• Monitor the budget. Look at the amount of money your project has actually consumed and determine whether your actual spending is more than originally estimated based on the work that has been completed. If so, be proactive. Either work with the team to determine how the remaining work will be completed to hit your original budget or else raise a risk that you may exceed your allocated budget.

5: Look for warning signs
Look for signs that the project may be in trouble. These could include the following:

• A small variance in schedule or budget starts to get bigger, especially early in the project. There is a tendency to think you can make it up, but this is a warning. If the tendencies are not corrected quickly, the impact will be unrecoverable.
• You discover that activities you think have already been completed are still being worked on. For example, users whom you think have been migrated to a new platform are still not.
• You need to rely on unscheduled overtime to hit the deadlines, especially early in the project.
• Team morale starts to decline.
• Deliverable quality or service quality starts to deteriorate. For instance, users start to complain that their converted e-mail folders are not working correctly.
• Quality-control steps, testing activities, and project management time starts to be cut back from the original schedule. A big project, such as an Exchange migration, can affect everyone in your organization. Don't cut back on the activities that ensure the work is done correctly.

If these situations occur, raise visibility through risk management, and put together a plan to proactively ensure that the project stays on track. If you cannot successfully manage through the problems, raise an issue.

MANAGING SCOPE
6: Ensure that the sponsor approves scope-change requests
After the basics of managing the schedule, managing scope is the most important activity required to control a project. Many project failures are not caused by problems with estimating or team skill sets but by the project team working on major and minor deliverables that were not part of the original project definition or business requirements.

Even if you have good scope-management procedures in place, there are still two major areas of scope-change management that must be understood to be successful: understanding who the customer is and scope creep.

In general, the project sponsor is the person funding the project. For infrastructure projects like an Exchange migration, the sponsor might be the CIO or CFO. Although there is usually just one sponsor, a big project can have many stakeholders, or people who are impacted by the project.

Requests for scope changes will most often come from stakeholders--many of whom may be managers in their own right. One manager might want chat services for his or her area. Another might want an exception to the size limits you have placed on mailboxes. It doesn't matter how important a change is to a stakeholder, they can't make scope-change decisions, and they can't give your team the approval to make the change.

In proper scope-change management, the sponsor (or a designate) must give the approval, since they are the only ones who can add funding to cover the changes and know if the project impact is acceptable.

7: Guard against scope creep
Most project managers know to invoke scope-change management procedures if they are asked to add a major new function or a major new deliverable to their project. However, sometimes the project manager doesn't recognize the small scope changes that get added over time.

Scope creep is a term used to define a series of small scope changes that are made to the project without scope-change management procedures being used. With scope creep, a series of small changes--none of which appear to affect the project individually--can accumulate and have a significant overall impact on the project. Many projects fail because of scope creep, and the project manager needs to be diligent in guarding against it.

MANAGING RISK
8: Identify risks up front
When the planning work is occurring, the project team should identify all known risks. For each risk, they should also determine the probability that the risk event will occur and the potential impact on the project.

Those events identified as high-risk should have specific plans put into place to mitigate them so they do not, in fact, occur. Medium risks should be evaluated to see whether they need to be proactively managed. (Low-level risks may be identified as assumptions. That is, there is potential risk involved, but you are "assuming" that the positive outcome is much more probable.)

Some risks are inherent in a complex project that affects every person in the company. Other risks may include not having the right level of expertise, unfamiliarity with the technology, and problems integrating smoothly with existing products or equipment.

9: Continue to assess potential risks throughout the project
Once the project begins, periodically perform an updated risk assessment to determine whether other risks have surfaced that need to be managed.

10: Resolve issues as quickly as possible
Issues are big problems. For instance, in an Exchange migration, the Exchange servers you ordered aren't ready and configured on time. Or perhaps the Windows forest isn't set up correctly and needs to be redesigned. The project manager should manage open issues diligently to ensure that they are being resolved.

If there is no urgency to resolve the issue or if the issue has been active for some time, it may not really be an issue. It may be a potential problem (risk), or it may be an action item that needs to be resolved at some later point. Real issues, by their nature, must be resolved with a sense of urgency.

Lateral thinking Puzzels

Acting on an anonymous phone call, the police raid a house to arrest a suspected murderer. They

don't know what he looks like but they know his name is John and that he is inside the house.

The police bust in on a carpenter, a lorry driver, a mechanic and a fireman all playing poker.

Without hesitation or communication of any kind, they immediately arrest the fireman. How do

they know they've got their man?

Hint: The police only know two things, that the criminal's name is John and that he is in a

particular house.

Answer: The fireman is the only man in the room. The rest of the poker players are women.


=---------------------------------------------------

A man lives in the penthouse of an apartment building. Every morning he takes the elevator down

to the lobby and leaves the building. Upon his return, however, he can only travel halfway up

in the lift and has to walk the rest of the way - unless it's raining. What is the explanation

for this?

Hint: He is very proud, so refuses to ever ask for help.


Answer: The man is a dwarf. He can't reach the upper elevator buttons, but he can ask people to

push them for him. He can also push them with his umbrella.


-------------------------------------------------------

How could a baby fall out of a twenty-story building onto the ground and live?

Hint: It does not matter what the baby lands on, and it has nothing to do with luck.

Answer: The baby fell out of a ground floor window.

---------------------------------------------------

A man and his son are in a car crash. The father is killed and the child is taken to hospital

gravely injured. When he gets there, the surgeon says, 'I can't operate on this boy - for he is

my son!!!' How can this possibly be?

Hint: his has nothing to do with adoption or time travel.

Answer: The surgeon can not operate on her own son; she is his mother.

-------------------------------------------------------

There are six eggs in the basket. Six people each take one of the eggs. How can it be that one

egg is left in the basket?

Answer: The last person took the basket with the last egg still inside.

Swap values of two variable in PHP

$a = 2;
$b = 6;
print_r(list($a, $b) = array($b, $a)); //Swap values of two variable in PHP
?>

How to change the date.timezone value in PHP?

If your PHP scripts do not show the correct time, the reason is that most probably your hosting server is in a different timezone. This can be easily resolved by changing a setting in PHP called date.timezone.

Depending on your location you can set a specific date.timezone value in PHP using the following option which should be added to your local php.ini file:

date.timezone = "US/Central"

The above example assumes you'd like to set the timezone for your PHP scripts to US/Central. The full list of supported time zones is available here and you should simply replace "US/Central" with the desired timezone.

In this article you can find additional information on how to change PHP values using the php.ini file. A helpful webhost can change the php timezone for you in no time.

10 signs of incompetent managers

I came across a great piece about traits that incompetent managers share. Written by Margaret Heffernan for FastCompany.com, this no-nonsense piece cuts to the chase and is about as true a list as I’ve ever seen. Here are the traits of incompetent managers, according to Ms. Heffernan:

1. Bias against action: There are always plenty of reasons not to take a decision, reasons to wait for more information, more options, more opinions. But real leaders display a consistent bias for action. People who don’t make mistakes generally don’t make anything. Legendary ad man David Ogilvy argued that a good decision today is worth far more than a perfect decision next month. Beware prevaricators.
2. Secrecy: “We can’t tell the staff,” is something I hear managers say repeatedly. They defend this position with the argument that staff will be distracted, confused or simply unable to comprehend what is happening in the business. If you treat employees like children, they will behave that way — which means trouble. If you treat them like adults, they may just respond likewise. Very few matters in business must remain confidential and good managers can identify those easily. The lover of secrecy has trouble being honest and is afraid of letting peers have the information they need to challenge him. He would rather defend his position than advance the mission. Secrets make companies political, anxious and full of distrust.
3. Over-sensitivity: “I know she’s always late, but if I raise the subject, she’ll be hurt.” An inability to be direct and honest with staff is a critical warning sign. Can your manager see a problem, address it headlong and move on? If not, problems won’t get resolved, they’ll grow. When managers say staff is too sensitive, they are usually describing themselves. Wilting violets don’t make great leaders. Weed them out. Interestingly, secrecy and over-sensitivity almost always travel together. They are a bias against honesty.
4. Love of procedure: Managers who cleave to the rule book, to points of order and who refer to colleagues by their titles have forgotten that rules and processes exist to expedite business, not ritualize it. Love of procedure often masks a fatal inability to prioritize — a tendency to polish the silver while the house is burning.
5. Preference for weak candidates: We interviewed three job candidates for a new position. One was clearly too junior, the other rubbed everyone up the wrong way and the third stood head and shoulders above the rest. Who did our manager want to hire? The junior. She felt threatened by the super-competent manager and hadn’t the confidence to know that you must always hire people smarter than yourself.
6. Focus on small tasks: Another senior salesperson I hired always produced the most perfect charts, forecasts and spreadsheets. She was always on time, her data completely up-to-date. She would always volunteer for projects in which she had no core expertise — marketing plans, financial forecasts, meetings with bank managers, the office move. It was all displacement activity to hide the fact that she could not do her real job.
7. Inability to hire former employees: I hired a head of sales once with (apparently) a luminous reputation. But, as we staffed up, he never attracted any candidates from his old company. He’d worked in sales for twenty years — hadn’t he mentored anyone who’d want to work with him again? Every good manager has alumni, eager to join the team again; if they don’t, smell a rat.
8. Allergy to deadlines: A deadline is a commitment. The manager who cannot set, and stick to deadlines, cannot honor commitments. A failure to set and meet deadlines also means that no one can ever feel a true sense of achievement. You can’t celebrate milestones if there aren’t any.
9. Addiction to consultants: A common — but expensive — way to put off making decisions is to hire consultants who can recommend several alternatives. While they’re figuring these out, managers don’t have to do anything. And when the consultant’s choices are presented, the ensuing debates can often absorb hours, days, months. Meanwhile, your organization is poorer but it isn’t any smarter. When the consultant leaves, he takes your money and his increased expertise out the door with him.
10. Long hours: In my experience, bad managers work very long hours. They think this is a brand of heroism but it is probably the single biggest hallmark of incompetence. To work effectively, you must prioritize and you must pace yourself. The manager who boasts of late nights, early mornings and no time off cannot manage himself so you’d better not let him manage anyone else.

Firefox/IE print preview/print issue. Cutting off after the 1st page

Use this style :

body {
font-family:Verdana, Arial, Helvetica, sans-serif;
margin: 0;
padding: 0;
font-size:100%;
height: auto; overflow: visible;}

10 ways IT departments waste money

IT is often a popular target for corporate cost-cutting. So the more you can identify and control unnecessary spending, the better youÂ’ll be able to fend off the budget axe.

Back in the golden days of IT, when companies had plenty of money to throw around, it didn't matter so much if there was a little wastage here and there.

Today, however, budgets are tight and there aren't many dollars to spare. That means IT departments need to take a good, hard look at where the money is going and where cuts can be made--before someone higher up does it for you.

In this article, we look at 10 ways you might be letting precious dollars slip right through your fingers. Some of these may seem to be just common sense, but there are organizations out there right now that are wasting money in all these ways.

1: Wasting energy
Despite some reduction in power costs over the last year, rates appear to be headed back up. The electric bill is still a large expense for most companies--and the IT department is a big user of energy.

You can save more money than you might suspect by adopting some energy-saving policies. Sure, most of the servers need to be accessible all the time. But IT personnel are often careless about leaving workstations running when they aren't doing anything and won't be accessed remotely or substituting the use of a screensaver for turning off the monitor (you should do both).

With the power settings available in modern operating systems, there's really no excuse for it, but some IT pros turn off power-saving features in favor of higher performance.

How about the practice of leaving lights on in offices and server rooms when no one is there? Most people don't think about the cost, but it can add up. Using more energy-efficient lighting and buying Energy Star rated equipment can also save big bucks over the long run.

2: Spending too much on mobile technology
Mobile phones and devices are "fun toys" for IT pros, but company-provided equipment and plans may be costing more than necessary.

A recent survey showed that only one out of four employees uses 75 percent or more of the voice minutes that their companies are paying for and almost half (48 percent) have services on the plan that they never use at all. As this article explains, many companies don't have viable policies regarding mobile device use.

3: Not allowing employees to work from home
Company managers sometimes fail to recognize the significant cost benefits--to both employer and employee--of allowing employees to telecommute all or part of the time.

One reason they oppose such an arrangement is that they won't have as much control over workers who aren't on site. IT departments sometimes support this position for fear that remote workers will present a security threat. However, with modern technologies such as NAP/NAC and DirectAccess, you can ensure that remote systems connecting to the company LAN are properly configured and protected and that the connections are secure.

Allowing more employees to work from home enables the company to save money on office/parking space and heating/air conditioning. Employees save money on clothes, lunches, and transportation. They also often enjoy work more, so they end up putting in extra hours that raise productivity and benefit the company. Many IT-related jobs, such as those of in-house developers and Web designers, can be done from home.

4: Using consultants when the job could be done by staff
It's a common scenario: Employees have been telling management for months or years that changes need to be made, but they've been ignored. Then the company hires a consultant, who charges tens or even hundreds of thousands of dollars to do a "study" and arrives at the same conclusion, providing the same advice staff members were trying to give away free.

If you have people on staff who have expertise in a particular area and have the time to do a job, it's generally more cost effective to allow them to do it than to bring in an outsider who has to spend many (billable) hours getting up to speed on how your company operates and what its specific needs are.

If you do find that you need to bring in a consultant, check credentials and references carefully. There are many good, hard-working IT consultants. The field is also a great target for rip-off artists who talk over your head about specialized technologies and try to push the latest and greatest on you--whether you need it or not--or attempt to sell you on specific products that you may not really need.

5: Hiring full-time employees when contractors would be more cost effective
The flip side of the previous item involves being afraid to use consultants or contractors when it's appropriate. Hiring full-time employees to handle a workload that's likely to be temporary leaves you with idle workers who end up costing you money because there's not enough for them to do to warrant their salaries--or forcing you to go through the pains (to those employees as well as to the company) of layoffs.

In these situations, when you don't have the current manpower or expertise on staff to get the job done, it's often more cost effective to hire independent contractors. Not only can you limit the duration of the commitment, but you don't generally have to pay for fringe benefits, such as insurance and vacation/sick time. You also don't have the administrative overhead of withholding taxes and filing the paperwork that's associated with regular employees.

6: Making unnecessary upgrades
There are good reasons to upgrade your software and/or hardware. When new operating systems or applications provide functionality that your users need or that can help them get their jobs done more easily or more rapidly, it makes sense to upgrade. When existing hardware won't run those programs you need, it may be necessary to buy new computers.

However, some companies follow a set upgrade schedule whereby they replace old systems every X number of years. Or they migrate to the new operating system or major application version X number of months after it's released, or as soon as service pack 1 comes out, or in response to some other arbitrary trigger--much like the old timer who "takes a bath every Saturday night, whether he needs one or not".

It makes more sense to carefully evaluate how the systems and software are being used and whether there's a real need to upgrade. You can save the cost of new licenses and administrative overhead costs--and often, make users happier and avoid deployment headaches--by sticking with what you have now if it's still working fine for your company's purposes.

This applies to servers, too. It's nice to have the latest and greatest running on the most powerful machines, but will it make a real difference in terms of productivity, security, and other important factors or do you just want it so you'll have a new toy to play with?

7: Failing to upgrade old, inefficient equipment
On the other hand, some companies are going overboard when it comes to squeezing every last drop of use out of their current systems.

If the computers are getting so old that they regularly break down and require repairs, if your servers go down so often that users of the network can't get their work done or customers can't access your site, if you're putting sensitive data at risk because you're depending on old software that's full of vulnerabilities, if the hardware costs considerably more to operate than more modern machines because it's so energy inefficient, it may be time to think about investing some capital to lower operating costs and save money over the long run.

Remember that neither software nor hardware upgrades have to be an "all or nothing" proposition. Some departments or individuals may need to be upgraded while others can get along for a while longer with what they have. And when you're considering a major upgrade, such as a new OS, it's often smart to roll it out with a pilot group first so you can work out any unanticipated problems before deploying across the entire organization.

8: Overspending on hardware
While buying new hardware can save you money, too much of a good thing can waste it. Some companies are still not utilizing virtualization to the extent that they could to reduce both capital and operating expenditures.

Instead of buying multiple mid-priced servers to run Web services, mail services, collaboration and communications services etc., you may be able to save substantially by purchasing one or two more powerful machines and consolidating servers with virtualization technologies. Not only is the total capital outlay often less, but you reduce the cost of extended warranties and maintenance contracts since they apply to fewer machines, and operating costs are often lower because the total power usage is less.

Another way some companies waste money is by purchasing equipment for a project that requires very intensive computing resources--but only for a limited time. When the project is over, you're stuck with the expensive equipment. An alternative is to use services such as Amazon's Elastic Compute Cloud (EC2) and similar cloud-based services that allow you to purchase capacity that can quickly scale up or down to fit your needs. Then, at any given time, you're paying only for the resources you actually use.

9: Not using the training budget effectively
Technology is always changing and it's important for IT personnel to stay current, but some departments waste money on training that could be done as effectively for much less.

Do employees really need to travel to a distant site for training or can it be done on-site less expensively? Perhaps instead of sending several employees, one can attend and then come back and share what he/she learned with the others. Or the same training may be available on DVD or through live online instruction at a fraction of the cost.

Is the department paying for certifications that may not be necessary? Certification provides assurance of a certain level of knowledge and in some cases, having certified employees on staff enhances the company's reputation or allows it to participate in vendor partner programs. But some IT professionals collect multiple certifications--at company expense--that may not benefit the company at all (although they may benefit the employee in looking for a new job).

Ongoing training is important, and having well-trained personnel can save a company money in the long run. But when budgets are tight, it's also important to get the most for every training dollar and cut out the waste.

10: Wasting money on travel expenses
Training isn't the only reason employees travel on the company dime. Members of the IT department may be called upon to attend meetings at company headquarters or give presentations at another branch office or go to a different location to help set up equipment or troubleshoot software problems. In a tight economy, it's smart to examine whether this things can be done via online meetings or through remote control software.

Sometimes, though, travel can't be avoided. In those cases, you can still save money by staying in more reasonably priced hotels, putting a cap on meals reimbursements or instituting a per diem, and even taking shuttles instead of cabs for small savings that add up.

When traveling only a few hundred miles, consider driving instead of flying. Given the hassle factor at airports today, it may not take much longer and can be a more pleasant experience, and the savings really accrue when two or more people travel together by car instead of plane.

Add Information and Image in My Computer

hen you open properties of My computer, what all information do you see? Most common things are OS details under System, Registered to "Your name", and Processor and Ram details under Computer.

What if you want to add more information? Yes, more information can be added to the My Computer properties. How?

Well I must tell you it is very very easy to do this, and believe me this is as simple as Cut Copy Paste

Here is what you need to do
Open Notepad, and type in the following.
[General]
Manufacturer= "You can type any information here"
Model="You can type any information here"
[Support Information]
Line1="You can type any information here"
Line2="You can type any information here"
P.S. - All the characters are case sensitive
You can add upto 10 lines in the Support Information section
Name this file as "OEMINFO.INI", and place it in System32 Folder
Just refresh and open My Computer Properties, and you will see additional information
To add an Image, follow these steps
Create any image of 125 X 125 pixel
Save it by name of "OEMLOGO.BMP"
Place this file in System32 folder
Refresh and you are done
If in case you want to undo these changes, just delete these files from system32 folder, and you will be back to normal.

Mohandas Karamchand Gandhi - Special

Mohandas Karamchand Gandhi, Mahatma Gandhi, the apostle of peace and the Father of the Nation was born on 2nd October 1869 at Porbandar in Gujarat.

Gandhi Jayanti is celebrated on the very day every year as the birthday of Mahatma Gandhi, Father of India.

In his autobiography My experiments with Truth Gandhi recalls that his childhood and teen age years were characterized by education in a local school, marriage to Kasturba at the age of 13 and an intrinsic love for’ truth’ and ‘duty’.

Gandhi, as he was popularly called, proved that non-violence is the most effective instrument of social change. His teachings are promoted even today to avoid violence and find peaceful solutions to conflicts.

Through his sheer dedication and self-belief, Gandhi freed India from the British Raj (British Rule). He proved to the world that freedom can be achieved through the path of non-violence.

For Gandhi ‘Non-violence’ and truth were two inalienable virtues. He summed up the entire philosophy of his life as: "The only virtue I want to claim is truth and non-violence. I lay no claim to super human powers: I want none".

The United Nations General Assembly announced on 15th June, 2007 that October 2nd will be celebrated as the International Day of Non-Violence.

The soul of India : Mahatma Gandhi

Some of the famous quotes by Mahatma Gandhi have been listed below:

· Live as if you were to die tomorrow. Learn as if you were to live forever.

· Fear is not a disease of the body; fear kills the soul.

· The principle of majority does not work when differences on fundamentals are involved.

· Freedom is not worth having if it does not include the freedom to make mistakes.

· It is better to be violent, if there is violence in our hearts, than to put on the cloak of nonviolence to cover impotence.

· It is unwise to be too sure of one's own wisdom. It is healthy to be reminded that the strongest might weaken and the wisest might err.

· You must not lose faith in humanity. Humanity is an ocean; if a few drops of the ocean are dirty, the ocean does not become dirty.

· Honest differences are often a healthy sign of progress.

· Whatever you do may be insignificant, but it is very important that you do it.

How to develop Leadership Skill

1. Know your people. Take time to offer a friendly greeting at the beginning of each workday. You will be amazed at how your greeting in the morning can set the tone of an employee’s attitude all day. A “grumpy” boss will most likely have “grumpy” employees. Let employees know that you care about them as individuals. So, talk to them occasionally about their outside interests.


2. Give plenty of feedback. Let people know you really do notice the work they do. Make specific comments about the work they do. For example, instead of just telling a person they did a good job, be specific about what was really good about their work. You might say, “I really liked the amount of detail you put into that report.” If it is details you want, give feedback on the amount of details they give. Also, expect inexperienced workers to make some mistakes. So, when mistakes are made with new tasks, assume first that your instructions were not clear, and take the time to clarify the expectations.



3. Never ignore non-performance. When you recognize someone is not meeting job expectations, check to see what’s happening. Identify and discuss the problem performance with the employee and let the worker know that you expect performance.


4. Praise workers who do what’s expected of them. Remember, a paycheck is not sufficient recognition for satisfactory job performance. Just praising the exceptional performance will mean few employees will be praised. It’s easy to praise top performers, but don’t forget the rest. Take the time to show those who regularly perform their work adequately that you appreciate their efforts. Remember, good performance gone unrecognized will diminish. If you don’t show you care about what they do, why should they care? If you don’t show you appreciate them, why should they appreciate you? I could go on, but you get the idea.


5. Remember the work atmosphere. The most important part of the work climate is a healthy sense of self-esteem. When employees feel good about themselves and they feel good about what they do it is much easier for them to be cooperative and display a willingness to go the extra mile for you. When you think about it, the attitude of the boss is the most important attitude of all. You set the tone.

Increase your hard disk speed....

To speed up your hard disk speed we need to configure a special buffer in the computer's memory in order to enable it to better deal with interrupts made from the disk.

This tip is only recommended if you have 256MB RAM or higher.

Follow these steps:

1) Run SYSEDIT.EXE from the Run command.

2) Expand the system.ini file window.

3) Scroll down almost to the end of the file till you find a line called [386enh].

4) Press Enter to make one blank line, and in that line type
Irq14=4096

Note: This line IS CASE SENSITIVE!!!

Click on the File menu, then choose Save.

Close SYSEDIT and reboot your computer.

Done. Speed improvement will be noticed after the computer reboots.

Folder option missing? Find Solution here

Many of us sometimes find the folder options missing in windows explorer.

Here's the solution—>

Open Run and then type "gpedit.msc" .
Now goto User Configuration > Administrative templates > Windows Component > Windows Explorer.

Click on Windows Explorer you will find the 3rd option on the right side of screen "Removes the Folder Option menu item from the Tools menu"
Just check it, if it is not configured then change it to enable by double clicking on it and after applying again set it to not configured.

I hopes that you will find the option after restarting windows.

Keep project scope small for success

Negativity can kill a project, but the opposite is also true: You can stuff a project with so many features that it's crushed by its own weight.

A common objection to a project plan is that it doesn't do enough--it doesn't have all the features that users will inevitably request, or it doesn't take certain situations into account.

Or as TechRepublic member biancaluna recently put it, it "does not solve world hunger nor does it wash my car or bake a pecan pie". But in my experience, those omissions argue for it rather than against it. Certainly, you don't want to preclude features that will be needed in the future, but if you try to anticipate all of those features in the initial design, you'll never complete that phase.

Rather than designing in everything from the top, start small but make your design modular and extensible.

In my response to biancaluna's comment I said: "In the future, whenever someone tries to shoot down an idea because it doesn't do enough, I'll say 'DNSWH'." Does Not Solve World Hunger. It's also a good response when someone is trying to pile on the features.

A company I used to work for had a long history of cowboy coding--that is, "we need feature X, so just go code it up." Naturally, after several years, this resulted in an unmaintainable mess; they got design religion and began requiring a lengthy design process before any code could be written.

To insure that nothing important was ever left out, they held daily design meetings involving a dozen or more people--each of whom was trying to impress everyone else with how many nits they could pick. Only a handful of projects ever emerged from this phase after months of bickering, and those projects went on to become bloated applications with so much feature noise that they were almost unusable.

What's even worse is that the projects didn't solve the original problem, which was to keep existing customers happy and to draw new customers in; instead, they focused on solving world hunger.

A number of times in my consulting career I've had clients want to ditch their product and start over from scratch. Perhaps the UI looks "old" and needs to be redone; or the code is so mangled that they think it is beyond hope; or they've hired someone who thinks that a certain language or framework is the philosopher's stone that will magically turn their applications to gold. These projects almost never succeed.

Why? Because they're too big. Yes, you can certainly recreate that application in Ruby on Rails in a fraction of the time spent on it to date, but do you realize how much time has actually gone into it? Chances are it's in the hundreds of thousands or even millions of hours. Even if you can develop ten times faster than the original, do you have several years to do this?

Sometimes it's easy to mistake how big these projects really are because their requirements aren't fully known. The projects have evolved over many years, and features are sometimes added without being documented; yet users rely on that behavior, and if you take it away, you're going to end up pasting it back in. Do that enough times, and your new, pristine version will end up being the same mix of baling wire and bubblegum that comprised the original.

It's almost always a better idea to make incremental improvements instead. That requires long-term vision of where you want to get someday, without trying to do it all at once. Lay out a general plan for the future, and then create a specific project to do just the first step. That helps to minimize the risk of failure and keep the project scope manageable.

It's easier to agree on the design for something that does only one thing well--and it's easier to tell when it doesn't. More importantly, you can get user feedback before you proceed to the next stage.

Trying to do too many things at once multiplies your chances of project failure. One company I worked for back in the 80s provided turnkey solutions--that is, they wheeled the system in, and all the user had to do was turn the key. The vendor provided the hardware, the operating system, and the software.

One bright day, the vendor decided to upgrade their database architecture. To do so, they needed a new version of the programming language and its runtime environment. That version was only supported on certain operating systems, so an OS upgrade would also be required for most users. The applications (mostly accounting) still needed regulatory changes, and they felt that they couldn't go a whole year without adding some enhancements as well.

To keep things "simple", they decided to do all this at once--to more than 1,300 supported users. It would be great--what could possibly go wrong?

The OS upgrades ran into hardware support issues. The language runtime was still pretty green on some platforms and introduced a massive number of failures--none of which showed up in QA, of course. But certainly a redesign of the database architecture should have been a simple task, right? No. Application bugs abounded due to touching just about every module.

The support lines were overwhelmed. Extra people manned the phones, including all the programmers. As a result, it took a long time to fix the issues. Meanwhile, we'd go home at night only after we attempted to call back every customer who had logged a call, but by then it was so late that they had given up on us--this added up to more than 700 users every night for months.

Did we keep all of our customers? No. Did we add any new ones? No, we tried to solve world hunger instead.

In retrospect, we should have taken on only one thing at a time. Upgrade the language runtime on one platform only where we already had users who wouldn't need an OS upgrade. Don't touch the database or the code until that's stable. Continue one platform at a time until the new runtime version is gold. Then look at changing the database--but only a portion of an application at a time.

Taking this sort of measured approach, we would have been able to slip in regulatory changes and even some small enhancements along the way, without breaking the customer's back.

For us consultants, limited scope is one of the key benefits of short-term contracts. In, done, out. But we can apply the same principle to long-term engagements as well by dividing each project into bite-sized chunks.

When a project looms massively before you, ask how you can cut it up so you won't choke on it. Identify the optional features and move those to the end, where they can be lopped off if you run short. Don't try to solve world hunger--feed one user need at a time.

Writing text file in UTF-8 encoding

fopen(sample.txt", "wb");
// adding header
$text="\xEF\xBB\xBF".$text;
fputs($f, $text);
fclose($f);
?>

Special ORDER BY handling without accepting any default sorting option of DB

select * from users where id in (11,10) order by field (id,11,10);

SELECT * FROM "comments" WHERE ("comments"."id" IN (1,3,2,4))
ORDER BY CASE "comments"."id"

10 skills developers need in next five years

For those looking to get ahead in your field or simply stay employed, this is not the time to be complacent. Find out what skills to work on now to maximize your future job prospects.

With the recent changes in the economy, a lot of developers are focused on their short-term job prospects.

At the same time, it's important to make sure that you get the most bang for your buck when it comes to taking the time and energy to learn new skills. Hence, here is our list of 10 skills you should be learning right now to make sure that your resume is relevant for the next five years.

The list is hardly exhaustive, and there are huge swaths of the industry it won't cover (mainframe developers, for example). Nonetheless, for average mainstream development, you can't go wrong learning at least seven of these skills--not only to the point where you can talk convincingly about them at a job interview, but actually use them on the job.

1: One of the "Big Three" (.NET, Java, PHP)
Unless there is a radical shift in the development world (akin to an asteroid hitting Redmond), most developers will need to know at least one of the Big Three development systems--.NET (VB.NET or C#), Java, or PHP--for the near future.

It's not enough to know the core languages, either. As projects encompass more and more disparate functionality, you'll need to know the associated frameworks and libraries more deeply.

2: Rich Internet Applications (RIAs)
Love it or hate it, in the last few years, Flash is suddenly being used for more than just animations of politicians singing goofy songs. Flash has also sprouted additional functionality in the form or Flex and AIR.

Flash's competitors, such as JavaFx and Silverlight, are also upping the ante on features and performance. To make things even more complicated, HTML 5 is incorporating all sorts of RIA functionality, including database connectivity, and putting the formal W3C stamp on AJAX. In the near future, being an RIA pro will be a key resume differentiator.

3: Web development
Web development is not going away anytime soon. Many developers have been content to lay back and ignore the Web or to just stick to "the basics" their framework provides them with.

But companies have been demanding more and more who really know how to work with the underlying technology at a "hand code" level. So bone up on JavaScript, CSS, and HTML to succeed over the next five years.

4: Web services
REST or SOAP? JSON or XML? While the choices and the answers depend on the project, it's getting increasingly difficult to be a developer (even one not writing Web applications) without consuming or creating a Web service.

Even areas that used to be ODBC, COM, or RPC domains are now being transitioned to Web services of some variety. Developers who can't work with Web services will find themselves relegated to legacy and maintenance roles.

5: Soft skills
One trend that has been going for quite some time is the increasing visibility of IT within and outside the enterprise. Developers are being brought into more and more non-development meetings and processes to provide feedback. For example, the CFO can't change the accounting rules without working with IT to update the systems. And an operations manager can't change a call center process without IT updating the CRM workflow.

Likewise, customers often need to work directly with the development teams to make sure that their needs are met. Will every developer need to go to Toastmasters or study How to Win Friends and Influence People? No. But the developers who do will be much more valuable to their employers--and highly sought after in the job market.

6: One dynamic and/or functional programming language
Languages like Ruby, Python, F#, and Groovy still aren't quite mainstream--but the ideas in them are. For example, the LINQ system in Microsoft's .NET is a direct descendent of functional programming techniques.

Both Ruby and Python are becoming hot in some sectors, thanks to the Rails framework and Silverlight, respectively. Learning one of these languages won't just improve your resume, though; it will expand your horizons. Every top-flight developer I've met recommends learning at least one dynamic or functional programming language to learn new ways of thinking, and from personal experience, I can tell you that it works.

7: Agile methodologies
When Agile first hit mainstream awareness, I was a skeptic, along with many other folks I know. It seemed to be some sort of knee-jerk reaction to tradition, throwing away the controls and standards in favor of anarchy. But as time went on, the ideas behind Agile became both better defined and better expressed.

Many shops are either adopting Agile or running proof-of-concept experiments with Agile. While Agile is not the ultimate panacea for project failure, it does indeed have a place on many projects. Developers with a proven track record of understanding and succeeding in Agile environments will be in increasingly high demand over the next few years.

8: Domain knowledge
Hand-in-hand with Agile methodologies, development teams are increasingly being viewed as partners in the definition of projects. This means that developers who understand the problem domain are able to contribute to the project in a highly visible, valuable way. With Agile, a developer who can say, "From here, we can also add this functionality fairly easily, and it will get us a lot of value", or "Gee, that requirement really doesn't match the usage patterns our logs show" will excel.

As much as many developers resist the idea of having to know anything about the problem domain at all, it is undeniable that increasing numbers of organizations prefer (if not require) developers to at least understand the basics.

9: Development "hygiene"
A few years ago, many (if not most) shops did not have access to bug tracking systems, version control, and other such tools; it was just the developers and their IDE of choice. But thanks to the development of new, integrated stacks, like the Microsoft Visual Studio Team System, and the explosion in availability of high quality, open source environments, organizations without these tools are becoming much less common. Developers must know more than just how to check code in and out of source control or how to use the VM system to build test environments. They need to have a rigorous habit of hygiene in place to make sure that they are properly coordinating with their teams. "Code cowboys" who store everything on a personal USB drive, don't document which changes correspond to which task item, and so on, are unwelcome in more traditional shops and even more unwelcome in Agile environments, which rely on a tight coordination between team members to operate.

10: Mobile development
The late 1990s saw Web development rise to mainstream acceptance and then begin to marginalize traditional desktop applications in many areas. In 2008, mobile development left the launch pad, and over the next five years, it will become increasingly important.

There are, of course, different approaches to mobile development: Web applications designed to work on mobile devices, RIAs aimed at that market, and applications that run directly on the devices. Regardless of which of these paths you choose, adding mobile development to your skill set will ensure that you are in demand for the future.

Keep management roles in a project separate

Clear separation of three distinct roles--project manager, technical manager and relationship manager--gives projects a better probability of success and client satisfaction.

I've been on both sides of the desk in IT projects; I've provided services to corporate clients as an IT project manager and consultant, and I've worked for large corporations as an IT executive.

Something I learned from these varied experiences is that, whether providing IT services as an insider or an outsider, every IT initiative is an engagement. Every IT effort requires that the service provider play three distinct roles: project manager, technical manager, and relationship manager. While many independent project managers and consultants attempt to play all three roles, they do so at the risk to themselves, the project and the relationship.

Requirements of a successful IT engagement
Every engagement, inside or out, must have: a clear business meaning, a defined success criteria, a technical plan, and a project plan, as well as sponsorship and stakeholder participation.

Whether you're engaged as an outside project manager to manage the development of a huge data center, or you're an inside IT tech migrating users from Windows XP to Windows Vista, these requirements are constant. These unchanging elements of a successful IT engagement require project managers to think carefully about how many hats they try to wear and to separate their roles into different, often conflicting, responsibilities.

On tiny projects, such as replacing one worn-out server in a departmental data closet, it may make sense from a financial and an efficiency standpoint for the project manager (if she's got the technical chops) to assume all three roles. Once projects get any bigger, my view is that it's good practice to have three individuals in the roles of project manager, technical manger, and relationship manager.

Three elements to manage
I often tell my clients that every engagement requires the superior management of three elements: the process, the content, and the relationship. Here are more details about each element:

• Managing the process is the project manager's role. She must ensure that a clear scope has been written, a meaningful estimate has been derived, and a complete project plan has been developed, along with all the other process elements required by her chosen methodology.
• Managing the content includes all the technical decisions: the technical specifications, the materials list, the software stack, and the integration of all these components.
• Managing the relationship requires that the needs, expectations, emotions, and politics that are an inevitable part of every human endeavor be successfully managed so that the perception of the end product matches the client team's vision.

I'd wager that every working project manager has a horror story to tell about an engagement that circled the drain, or outright failed, because at least one of these elements was mismanaged.

Three roles of management
So why do I believe so strongly that it's a mistake for the project manager to try and take on all three roles (except in the smallest engagements)?

First, it's a skills and temperament issue. My experience is that project managers who excel in the process elements--following their chosen methodology and focusing on the details of time, scope, and function--often haven't developed their technical and relationship skills to the same degree.

The never-ending debate in the project management community over whether project managers must be technical proves that this is still perceived as an issue. There are exceptions, but developing strong project manager skills, getting certifications, and keeping those certifications current is challenge enough without also trying to stay ahead of the surging wave of technology developments.

More important than the skills and temperament issue is the simple fact that trying to play all of these roles is an irreconcilable conflict of interest.

I tell my students that project management is not a popularity contest; the project manager's role is often to play the "bad cop". The project manager needs to be the one to tell the client that the inside IT team is not pulling their weight, that the bug list is growing instead of shrinking, or that their genius developer is not such a genius after all.

While it's important for project managers to use diplomacy when delivering these messages, they must ensure that the client gets the message.

The technical manager must take ownership of the entire technical design, which is a daunting task, especially as projects grow in complexity. He doesn't need (and is often unprepared) to deal with the process and relationship issues that arise from his recommendations. The necessary actions of the project manager and the technical manager can lead to strained relationships if not handled with subtlety.

This is where the relationship manager comes in. In a contractor relationship, this manager is often the salesperson who introduces the contracting organization to the client and must keep that relationship on an even keel in order to get the current engagement delivered and to mine for additional projects in the account.

In this case, the relationship manager has a financial incentive to closely manage the relationship. Yet, even in inside IT initiatives, someone needs to ensure that the client and the stakeholders are satisfied, are getting the results they expect, and are willing to trust the IT delivery team to do future projects.

There are practical issues to this separation of roles. For instance, not every engagement can afford to have three team members doing these duties, and not every engagement is complex enough to require them.

Joomla Some good Plugins/Extensions

Joomla Some good Plugins/Extensions

Menus - swMenu

Events : redEvent

Newsletter: ccNewsletter

Photo Gallery: expose4

Video Gallery: expose4

Team Building and employee motivation techniques

One of the most important steps of a project is to carefully choose the team. This is not an easy job to do, because it requires a lot of objectivity and you must keep in mind the goal of the project and not the sympathy for certain persons. Before choosing the team you must think what kind of specialists you need exactly and this is the main thing you must consider when you choose the members: their specialty and your need for it.

Most of the times, having to choose a team means forgetting about sympathies and friendship and doing the right thing for the sake of the project. And because team building means more than just choosing a team, and also growing it and educating it, this also represents forgetting about yourself sometimes, especially when you’re the Project Manager or the responsible person for the success of the project.

The qualities needed for every project are patience, involvement, openness to suggestions and indications, pleasure and easiness for team working, etc.; but besides these there are also others to keep in mind and that regard strictly the type of project you’re working on.

It’s good to remember that team building means a lot of team coordination, a lot of suggestions and indications to give and a lot of questions to be asked. And this is something that takes place starting with the beginning, when you choose the people, and ending with the reach of the goal, when you finally take a break and celebrate.

Team building means talking, discussing, asking and answering, being ready for brainstorming or for working more than usual, listening and asking for suggestions, respecting and following the indications received, keeping the moral as high as possible and motivating the people when needed. All these are team works so, basically, team building doesn’t regard only the project manager’ tasks, but the whole team’.

Most important steps for a successful project

How many times have you heard about or been involved in a project that failed miserably? Or perhaps it just was not as successful as it needed to be. Did you ever spend time looking back to see what caused the project to go wrong. Next you have a few tips to help you understand what it takes to build a successfull project.

First of all you must know exactly what's your project about. You must discuss it with your team(if you have any) and you must agree precise specifications for it. You cannot start working until you have a well-defined idea in your mind.

Second of all you must plan the project. Here you should consider the time you need to finish it, the team you can relly on, the activities that must be done, the resources you have, and, of course, the financials.

During working time it's very important to communicate a lot with your team, to let them know what you managed to do, to ask questions and to give answers when needed. A lack of communication can lead to the failure of the project.

Also you must keep in mind to motivate and encourage your team when needed. You started the project as a team and you will finish it the same.

When the project is almost done you must check, measure and review it's plans. If you notice that something's wrong, you must inform you team and correct the errors. It's recommended not to leave this for the last moments when you don't have enough time to change anything.

After completing the project you must review it once more.If you are not pleased, don't start changing things because it could only be worse. It's very important to keep the armony and the well-organized shape of the project and changes on the spot can seriously affect that.

Some tips about project initiation

To efficiently initiate a project you need to keep in mind a few steps that will only lead to a good and organised work. So, first of all, you must document the business opportunity and find alternative solutions available. You can even search for similar ideas that have already been developped.

Second of all, you must conduct a Feasibility Study to investigate the chance of succes that you and your project have. This requires a lot of objectivity. It's important to know exactly how you stand and what are your chances of failure.

Third of all, you must consider new technologies for your project. It can be very helpfull, but it can also represent a risk because if anything can go wrong, it usually does. So don't try to make your work easier because you risk you make it harder.

And of course, after planning and discusing the project, after all the calculating part, you must start working. But you must keep in mind that the most important part of a good project it is it's initiation. When you start something like you should, it will be good. And when you don't, it will surely be a total mess.

Developing key performance indicators in projects

should preferably meet the following essential criteria:

• Be direct (no complex calculations)
• Be objective
• Be adequate
• Be quantitative
• Be practical
• Be reliable

Developing key performance indicators is best done in a kick-off meeting during the planning phase of a project.

It involves the following steps:

• Carefully consider the results desired
• Avoid overly broad results statements
• Develop a lot of possible indicators during a short brain storming session.
• Assess each indicator against the above criteria (be direct, be objective...)
• Select the best performance indicators

It can be an iterative process: if the resulting indicators do not look too good, restart a new brain storming session.

Hold People Responsible and Accountable

Generally responsibility for a project means: delivering on plans and commitments, being part of the team, acknowledging when there are problems and being willing to adjust personal priorities in favor of the overall project priorities.

First of all inside of each project and teams there must exist a set of rules that must be respected by all team members. For not respecting these rules there must be also penalties because most of the times people respect rules just because they fear the penalties.

Responsability also means being honest with yourself, understanding and accepting the quality of your work and the stage of your project. You cannot fool yourself because this only leads to failure.

Each person involved in a project has his own responsability. The Project Manager for example is responsible for clearly defining what is expected from each member of the team. The members of the team are responsible for maintaining conssistency, for asking help when they need, for reporting the problems that appear, for asking advices when they need.

Responsability also means feeling compasion and understanding a team member that doesn't fit in the project team and trying to help him. But this should never overcome incompetence because the final goal of the project counts the most.

Even if it's hard to do it, sometimes responsability also means removing someone from the team when he's guilty for intolerable situations like: abusive treatment or language, any discriminatory or derogatory words or actions, violence (including verbal assault) or any other physically inappropriate behavior.

Mainly responsability is knowing all the time what you want to do for that project, how it's supposed to be and dealing with people according to this. A lack of responsability can lead to a failure or to disputes between team members that's why it's good to maintain the objectivity no matter what.

How should I deal with changes to my project?

Changes to projects are something that always happen and we can't help from feeling them. It's normal to deal with changes during a project because during the project work progress you make new discoveries, you encounter problems which you must fix and you have new ideas that can improve the progress.

Generally speaking, there are 3 main categories of changes:

• changes that regard the time (the deadline of the project),
• changes that regard the resources available (people and money needed)
• and changes that regard the output (the form of the deliverables.)

You must keep in mind that any of these categories of changes can affect the end of your project and it depend of you to control it.

Generally changes occur step by step during one project and they are not so significant. But there are also situations when changes can be major and they can have a serious impact on the project.

In order to protect yourself and your project from big changes that can damage it, you should be ready for them and when they appear analyze them very well. To do this, you must consider the following questions and ideas:

• who needs the change,
• what is supposed to be changed and why,
• how important is that change for the project
• and what will happen to the project if you make the change.

It's important to know how to deal with important changes. Because those can really cause damage to your project and you should know very well their results before actually doing them. So if you are not sure that a change will affect in a good way your project, then better don't do it or do it very carefully.

Another thing that you should consider before changing something to a project is the authority that you have or don't have to do this. Because you wouldn't want to change something that will end up bad without being authorized to do it. If you are sure your change will be a good one, ask for permission first and then act. Don't rush into taking decisions or making changes because you might be wrong.

While you make a change you have to be very careful and to pay a lot of attention to it because it can have unexpected repercussions. For example when you change one of the team's member because he's more qualified for that job you can seriously affect team spirit.

The most important thing to remember about changes is that they simply occur. Sometimes because they are needed and sometimes by mistake. But If you pay enough attention to them the situation of your project can improve or at least remain the same, without being damaged.

When to reward your team

Traditional practices of rewarding project members at the end of a project or the month are far too common to give your team’s motivation that edge they need to really focus on their work. Instead, you should look at more creative and personalized solutions to rewarding your team. Not only will it build better rapport and boost team morale, the end result in terms of your project is likely to be much improved in quality.

Adjust your bonus policy to incorporate giving mini-bonuses throughout a project (or even at the start of one). Too often organizations get caught up in the thought that if you give your employees too much too quickly, they’ll start lagging behind in their work and take the organization for granted. As project managers, it would help to break out of the mold and instead, reward your team when you decide it will help their productivity the most. Giving a team member a break (or an effective rotation policy) during a project can very well boost their productivity by several levels. A short break can even be given before the start of a grueling project.

Similarly, if you are awarding monetary bonuses, there’s no need to wait till the end of the project (especially if this a demanding project). If a team member really excels at a certain phase, it’s much better to reward them with a mini-bonus right there. This will not only motivate them further, but also provide other team members incentive to improve.

Why over-delivering should be part of your project plan

Over-delivering has become the buzz word in internet marketing circles, and there’s good reason for that. Going beyond the expected requirements of a project not only gives your team a sense of accomplishment (especially if it is a tough project), but it also raises the bar and motivates the team to work harder and better. Ideally, over-delivering should not be part of the initial solution but something that is factored into the internal project requirements. Subsequently, it should be monitored, the additional requirements evaluated and milestones (if any) realized just as other components of the project.

Over-delivering isn’t always easy. For one, it sets a standard that you are then expected to follow, and this can turn into a vicious cycle if not taken care off. Instead of blowing the roof and doing twice the amount of required work, keep the over-delivering to a maximum of 10 to 20 percent of the total work. This sort of value-added delivery not only endears you in the eyes of your clients / superiors, it automatically adds to the benefits you and your team receive as a result. In the long run, a committed approach to over-delivering on your projects will afford you more clients, and within an organization, a reputation for doing the best work. That can only help you and your career.

Software Project Management

Part 1: Overview of software project planning

Software development has inherit problem with determining the time it takes to complete it. Software programming is quite different than say, nail production. When one produces nails it is known how many nails machine produces per hour. If you need to produce x number of nails figuring the time it takes is easy. If you need 12h of time, you know that one of your workers can handle the overtime and omitting for the sake of argument certain safety concerns, your worker will be as productive at hour 1 as hour 12. Unfortunately, software development is much harder than nail manufacturing. There are many more unknowns - risks that have to be accounted for.

• Risk management
• Avoiding common mistakes
• Practicing development fundamentals
• Following practices leading to best possible schedule

The reason for "might" is the risk based aspect - as mentioned before things may go right or wrong. It's all about leaning in favor of successful resolution instead of using methods that increase the chance of failure. One of the methods that increase risk, but are widely used due to their simplicity, is programmer total commitment. This disorganized way of project management has its successes, however these successes are a result of inefficient, hard work - not of smart work that can be achieved by following above four principles.

Part 2: Development speed

• The speed with which project is completed depends on four competing factors that are pooling the project in their respective directions.
• To achieve rapid development, you need to optimize all four factors listed underneath:
  • People - select top talent that is motivated in well organized team structure
  • Technology -
  • Process - create customer oriented software that incorporates high level of quality achieved with help of development fundamentals. Manage risks with lifecycle model and efficient use of resources.
  • Product - remember that size does matter, flexible requirements help in shortening of schedules.

Part 3: Most common mistakes

• People
  • Management decreased developer motivation.
  • Under-trained developers, developers with low qualifications.
  • Keeping problem developers (non-team players) on the team against wishes of all other team members.
  • Company encouraged developer "heroics", emphasis on "can-do" attitudes.
  • Adding people to projects that are over-running their schedule.
  • Working environment that prevents developers from focusing on their work. Customer interactions that are too frequent or lead to open conflicts.
  • Unrealistic expectations, usually in the area of project scheduling, wishful thinking.
  • Absence of executive project sponsorship, absence of agreement between all parties involved in the project.
  • Absence of customer involvement in the project causing delivery of software that doesn't meet customer expectations which in turn cause feature creep.
  • Involving developers in company politics more than is necessary.
• Process
  • Schedules that are to short for the project at hand - too much emphasis on optimism.
  • No risk management or insufficient risk management.
  • Problems with contractors (part of risk assessment)
  • Luck of, or insufficient project planning. Throwing out plans when placed under excessive pressure to complete project. Deliberately omitting non-code related activities, like design, due to excessive pressure.
  • Spending excessive amounts of time on project approval and budgeting.
  • Poor design and poor quality assurance.
  • To few controls placed on the development process causing schedule slips to go unnoticed.
  • Attempting to enter project "polishing" stage to early or more than once (frequent attempts to get it shipped).
  • Thinking that project which is in trouble can be saved by "catch up" later on.
• Product
  • Too many requirements, attempting to build systems that can do everything.
  • Adding to many new features to the ongoing project - feature creep.
  • Allowing developers to use new technology project for reasons other than project requirement.
  • Attempting to treat software research as regular software development.
• Technology
  • Silver bullet technology syndrome, over-estimating benefits of new tools and technology.
  • Changing tools or methods in the middle of the project.
  • Failure to keep code backups, no source control software.

Part 4: Software development fundamentals

• Development fundamentals reduce time and cost needed to develop software. However, they are not sufficient to develop software quickly, they are only necessary conditions for rapid development (ie if you don't have them you are almost certain to fail, but if you have them you are not guaranteed success).
• Development fundamentals can be divided into three areas that share fuzzy boundaries, non-technical, technical and quality assurance
• Non-technical fundamentals control all aspects of well known trade-off triangle (time, cost and product quality)
  • Ability to estimate project size. Once project size is narrowed down, ability to estimate effort needed to develop project based on project size. When effort needed is known, rough schedule can be created.
  • Ability to plan and stick to the plan under pressure. Planning can be further broken down into these components:
    • Team members, team size and team organization.
    • Lifecycle model choice.
    • Control over feature set.
  • Measuring progress through milestones (or micro milestones), reports, meetings etc.
  • Recording project statistics, at least cost, schedule performance and quality (three aspects of trade-off triangle).
• Technical fundamentals require knowledge of programming principles and experience in their application.
  • Ability to manage requirements can be further broken down into smaller parts:
    • End-user or customer involvement in requirement gathering process, for example through interviews
    • Making sure requirements are complete
    • Preventing frequent changes to requirements
    • Using requirements analysis methodologies, like object oriented analysis
    • Good graphical modeling of whole or partial systems, for example database diagrams
  • Good design
    • Good design starts with a choice of design style, for example object oriented design
    • Each design style has its own set of design concepts, for example inheritance
    • Using patterns to solve well known problems
    • Use of design software for large projects
  • Production of code that is of high quality
    • Naming and inline documentation conventions, rules for creation of new files and packages
    • Standard practices that lead to good code, like use of constants for values that don't change over time
    • Error detection
    • Unit testing and integration rules
    • Code refractory and optimization
    • Use of other software programs in creation of code, for example IDE choice
  • Management of software configuration deals with keeping the project feature set under control, most important feature set management technique is a change board. It decides what features are in and what features are out.
• Quality assurance is more than just testing
  • Ensuring that code created is of high quality (as described above). Code used for testing purposes should also be of high quality.
  • Focus on defect detection in early stages of project development, not just in code but also more importantly in earlier stages, such as requirements gathering.
  • Re-writing of all pieces of code that have high defect rate.
  • Remember that testing final product can show that it is of low quality but it cannot prove its of high quality.
  • Reading code is a good bug catching activity
  • Formal inspections are used to check adherence to project specifications on "industrial" scale. Each inspection team member has a specific role. Inspections are done on each major stage of project development. Inspections start with requirement inspection and end with final product inspection.

Part 5: Risk management in software development

• Risk management in general is a relatively new discipline, with software risk management playing the role of one of it's most recent advances.
• Risks come in three different forms, each associated with a branch of the "trade-off triangle". Software projects deal with risks associated with schedule, cost and quality.
• The goal of risk management is to minimize crisis management and failure and fix management styles while at the same time maximizing the prevention and elimination of problematic areas of the project.
• In order to achieve above goal risks have to be assessed first and then put under control.
• Risk assessment is made of:
  • Risk identification
  • Likelihood of events identified as risks
  • Impact study of each risk, with priority given to most dangerous scenarios
• Risk control is made of:
  • Preparing list of actions that have to be taken when each predicted event takes place
  • Making sure risk resolution plan is followed
• There are too many different types of risk to be enumerated here. Risks generally are mirror image of best practices, for example, inadequate design is a risk, while good design is a best practice.
• Risk exposure is the likelihood of the event multiplied by the impact the even will have. Events that are common but have small impact will produce the same risk exposure as events that are rare but have large impact.
• Risk resolution techniques can be as simple as avoiding the task that is risky, to as complex as development of contingency plans.
• Risks don't stay static throughout project development, they change. Risks need to be monitored. A good way to monitor risks is to keep a list of the most current top 10 risks.
• Be aware of projects that are very risky, projects with more than 90% failure probability. These projects don't pay in the long run.

Part 6: Choosing right development style

• There is no one single best practice that leads to the best software development method. For each specific project a method has to be chose that is appropriate for it. For example, mission critical software products have to be of much higher quality than a screen saver software.
• Not all projects need to optimize their development speed, many upper managers ask for speed but mean other things. For example, client will talk about quick development when they really want to minimize project overall cost.
• Unless product has a strong schedule constraint development speed might not be of top priority. If speed is not the most important factor, concentrate on quality.
• Remember, you can deliver projects with only 2 branches of the trade-off triangle.

• There is an absolute limit on the minimal time it will take to complete any given project.
• Projects cannot have 100% probability of completing on any given time because they involve risks (not everything in a project is certain) thus we are dealing with probabilities of completing on a given date.
• Projects that are rapidly developed can be seen by customers as slow because they don't provide a lot of feedback as to project progress.
• Remember that cutting time from the top most (done 1st) stages of the project will force you to pay back in time many times over in lower stages of the project. For example, design flow will cost much more to fix in the construction phase than design phase.

Part 7: Choosing right lifecycle model

• Lifecycle model gives order to operations performed from the time of project start (when the software is just an idea) till project completion (when project is absolute, no longer supported).
• Every project uses a lifecycle model, even if such model is not defined at project's start. You are using it even through you don't know about it.
• Every lifecycle model (other than code and fix) has the following essential phases:
  • Software concept - initial idea
  • Requirements gathering and analysis
  • Software design
  • Detailed software design
  • Coding
  • Debugging
  • Testing
  • Software delivery, project completed
• If an organization doesn't know what life cycle model they are using when asked, it means they are using code and fix lifecycle model.
  • Code and fix model was introduced together with the earliest software, in 1950's.
  • Through most organizations see this model as "evil" it does have few advantages and legitimate uses.
  • This model doesn't require any training - its natural, everyone knows how to use it without any training.
  • It shows signs of progress immediately since no formal planning is performed, programmers jump into coding phase right after initial software concept gets approval of upper management.
  • This model is good for tiny projects or for throw away one time only code.
  • For larger projects the list of problems with this model is very long, lets just leave it as an exercise to the reader to come up with a list based on premise "if you don't plan ...".
• The most basic and earliest organized life cycle model is called waterfall lifecycle model
  • This model goes from one stage to the other of software development in linear fashion
  • The waterfall model is old and has many known weaknesses, however, for some projects it is still very useful. It works well with complex projects that have very well known architecture. This model places emphasis on software quality, not on speed or cost of the software development.
  • Main weakness is outlined above already, most projects don't have requirements written in stone. Waterfall model is very inflexible - it is not the model that accepts change even in moderate amounts. It is a fact that most end-users, the customer that requests the project, don't know what they exactly want before project is commenced. Thus, the waterfall lifecycle model is not practical when faced with realities of everyday life.
  • Other problems include excessive amounts of documentation and very few signs of progress.
• Spiral - cinnamon roll model
  • The main idea behind creation of this model was risk control. This model is designed to minimize risks associated with software development.
  • This model divides the whole software development into a series of iterations. Each iteration can include the following five steps. Note that these are only basic steps iteration can include, depending on aim, some steps can be omitted, some may be added.
    • Plan out iteration objectives, prioritize objectives, plan alternatives.
    • Identify risks associated with objectives and route to their resolution.
    • Develop objectives (for example code).
    • Check whatever objective aim was achieve, quality assurance.
    • End current iteration, start planning next iteration, if one is needed.
  • Note that iteration(s) are needed for each of essential software phases.
  • This model is highly customized, the main idea is that of an iteration. Some iteration can take a form of another lifecycle model. For example, you may start with "regular" spiral model and finish with waterfall model once all risks are taken care of.
  • This model has one noteworthy disadvantage. All this flexibility comes at a price, this is one of the most complex lifecycle models. The trade-off is simplicity for flexibility. Note that most simple models like code and fix or standard waterfall are easy to master.
• As deficiencies of waterfall model became apparent a number of modified waterfall lifecycle models were created. Each of these models resembles standard waterfall in that it is easy to learn, but attempts to fix at least one weakness of the standard waterfall model.
  • Sashimi lifecycle model is a standard waterfall model with overlapping stages. It allows more flexibility in movement between consecutive phases. This comes at the price of unclear progress as phase boundary is fuzzy.
  • Waterfall with sub-projects lifecycle model trades increased (perceived and maybe real) speed of development for increased risk. In this model after software architecture is designed (on high level, not detail) project is divided into a number of small waterfall based projects that work in parallel. The idea is that some of these will produce results quicker than others. Problems could arise if unforeseen system inter dependencies are discovered between projects that are assumed to be separate.
  • Risk reduced lifecycle model was already discussed under spiral model as a possible modification. In this model risk is reduced by using spiral model for initial project design and proceed with standard waterfall model from detailed design till project delivery.
  • Staged delivery model proceeds as standard water cycle model until end of design phase. At this stage the project is divided into a number of phases that include all other stages of waterfall model. Important functionality is implemented in early stages allowing the customer to use the product as soon as few stages are complete. The main disadvantage of this project deals with large amount of planning needed for each stage. This model can also be adopted for projects on tight schedules. When a deadline that is immovable is reached, product completed some of its planned stages and can be shipped with most important functionality already implemented.
• Evolutionary prototyping model starts with a prototype that implements as many prominent visible features as possible. This initial prototype is then modified as per customer input until it is shipped as completed software product.
  • This model is great for projects that have rapidly changing requirements, projects where customers don't know or are unsure as to what they want.
  • The main disadvantage of this approach is related to the risk that uncertain customer brings to the project. If we don't know what the customer wants, we cannot know how long it will take to build.
  • Care must be taken to avoid morphing evolutionary prototyping model into a code and fix model.
• Evolutionary delivery model is a hybrid of evolutionary prototyping and staged delivery. In this model each prototype completed and a stage.
• There are many more lifecycle models to choose from. Each project is different. A choice of lifecycle model should be made with these point in mind:
  • How well do customers know what they want.
  • How well does the developer know system he needs to build, its architecture.
  • What is the overall system quality that is expected.
  • Future version planning emphasis.
  • What is the level of risk in this project.
  • What is the schedule like, is there a deadline that cannot be moved.
  • How much visible progress does the customer want.
  • How experienced is the development team.

Part 8: Project estimation

• Project planning is based on the ability to estimate project size and create based on size estimate project schedule.
• Software schedule estimation is "hard" because initial estimates are based on process plagued by multiple unknown factors. Thus, initial estimates are very inaccurate. As more is known about the project, schedule can be refined.
• At product definition stage there are many unknowns, thus projects estimated effort (and size) has a potential error of +500% and -%30 (with some large confidence interval, say 95%).
• Confidence intervals are used in statistics to measure how sure is the statistician that the phenomenon measured will fall within the range computed. Common confidence intervals are 90%, 95% and 99%. As confidence interval approaches 1 the range widens since it has to account for many unlikely events. 95% confidence interval is a good start.
• It is a good idea to refine project schedule after each milestone or stage is complete. Schedule should be more precise as it is based on more stable data.
• Parkinson's law: work expands to fill in available time. This implies that schedules that assign to much time to a project just to be safe risk loosing efficiency.
• In order to produce an estimate, the following estimates have to be completed:
  • Product size estimate - can be number of lines or number of function points (IBM method) or using special software
  • Product effort estimate - how many man-months will it take to complete project of given size
  • Schedule estimate based on effort needed, easy compared to above two steps, many formulas exist for automated computing
• Function points are also known as IBM method of 1984. A function point is assigned per certain level of complexity of either input or output to the software system.
• Jones's First-Order estimation is a method of deriving a rough estimate from function point count. A table is used to determine, based on software class, the exponent to which function point count needs to be raised in order to get number of months project will take to complete. For example, for average business software the exponent is 0.43.
• Lines of code make for an easier then function point estimate, however, same task written in different language requires different amount of code lines. For code line count only lines with the actual code are counted. Tables are used for projects that will need at least 10000 lines of code. Anything less than 10000 is usually done by single person and is correlated to abilities of that individual.
• The following are best practices for software estimation:
  • Never make "quick estimates". If you are forced to provide a number, make sure you provide a disclaimer as to its luck of accuracy.
  • Don't argue about the estimate or schedule - they are fixed and non-negotiable. Instead try to change inputs that produce the estimate.
  • Commitment based scheduling, where each developer commits to a schedule has a major problem related to natural tendency of developers to be too optimistic. The encouragement of optimism by managers makes for very inaccurate scheduling.
  • When estimating make sure you compare results to similar past projects. Make sure your estimates include trivial, common or obvious tasks.
  • When presenting an estimate use a range and/ or confidence interval. You don't need to be precise in range estimates, for example, you may say that in the worst case project A will be completed in the middle of December.
  • The best tool in project effort estimation is company's historical data.
  • You cannot refine project estimate before project start, even with more time. Refinement can only occur once project progresses.
  • When project is missing milestones, multiply the project estimate by 1 + amount of slip / old estimate - current project progress. For example, if a project with original schedule of three months is late one week, 6 weeks into project, then new schedule = 3 * {1 + 0.25/(3-1.5)} = 3 * 1.166 = 3.5
  • Project almost never catch up once they are behind unless project cost and/ or project features are changed in order to decrease project effort.
• Schedule can be derived from the following formula: schedule in time periods = corrective factor * man time periods ^ 1/3. Most typical time period is a month. Corrective factor varies, it can be anywhere from 2.5 to 3.5, with 3 a good guess.
• Schedules can be compressed:
  • Schedules can be compressed, however, compression of a schedule requires exponential increase in required effort.
  • Compression factor = desired schedule / initial schedule
  • new effort = initial effort / compression factor
  • It is believed it is impossible to achieve compression factor of less than 0.75.

Part 9: Scheduling

• It is rather easy to go from project size to project size and then to schedule estimate when compared to the task of getting schedule accepted.
• Higher management almost always pushes for overly optimistic schedules.
• Problems with schedules can be traced to wishful thinking of management/ customers and poor negotiation skills of the project manager.
• Most common scheduling mistakes:
  • Start project polishing procedures earlier than planned
  • Not adhering to plan when project runs behind schedule
  • Luck of good project planning
  • Too much pressure on development team causing dramatic increase in error count and loss of team morale.
  • Forgetting about the customer.
• Remember that you cannot cut out of the schedule non-code related activities since skimping on them will cause dramatic, as high as 10 to 100, increase in coding and testing.
• Good negotiation technique that is easy to learn is based on creation of "win - win" scenarios for both sides of the negotiation. This technique has four aspects that need to be followed:
  • Make sure objective criteria are used while discussing the schedule - the most important criteria is related to the schedule for given work - this is written in stone and cannot be changed, what can change is the work effort or expected cost (trade-off triangle).
  • The focus of the conversation should be aimed towards interests of both parties, not their positions/li>
  • The discussion is about the schedule, not people on either side of the table - as little emotions as possible
  • Aim at options that are going to benefit both sides, play with the trade-off triangle
• Insist on the schedule you have come up - its better to stand by and weather the rain then be under the drainpipe later on, once the project gets out of hand if your schedule is not followed.

Part 10: Developing for a customer

• The supreme goal of every software project is to create a product that is going to satisfy product users - customers. When customers are happy, everyone else in the company is happy.
• Not all solutions created by the developers are good for the customers.
• One of the most costly mistakes that can plague project development are related to development of products that end-users don't want to use. Creating something that was not expected by the customer leads to massive waste of money, as ultimate goal of producing what the customer wants is as (almost) as far away as when the project commenced.
• In order to produce product that customer(s) want, the following techniques of communication can by applied:
  • Requirements analysis - you need the "real" requirements, use techniques like user interface prototyping and focus groups to find out what customers really want to see in the product you are creating for them.
  • Project planning - you need to find out who you need to satisfy and establish good communication with that group of people.
  • Design - what you need to create is never written in stone, also, things will evolve later on as no project stays final for long. Thus, plan to change, create flexible designs (but not too flexible).
  • Actual coding - customers like to see project progress, it makes them feel safer, your job (as well as everyone else's in the company) is to keep customers happy - thus make progress visible to your customers.
• What customers expect and what developers can deliver frequently is not written on the same page. This leads to problems later on in project's life. Make sure customers know what they should expect as far as project cost, speed and functionality is concerned. Never lie to your customers, as a lie will sooner or later come out of the closed and poison your relationship with your customer.

Part 11: Developer's motivation

• Developer motivation is the most important factor in determining that developer's productivity. The difference in productivity between unmotivated and very motivated developer can be as high as 1:10.
• It is hard to measure effects of motivation on productivity since motivation is not a material entity.
• Different people are motivated by different things, for example, software developers are motivated as a group by different things than average manager. The difference is quite wide - developers frequently motivated by opposite factors than their managers.
• Some of the most important motivating factors for developers are:
  • Achievement recognition - set a goal that developers can aim for, be it fastest code or shortest amount of code. Let developers take control of the project, like setting up their own ambitious schedules.
  • Growth in their chosen IT profession - make sure your staff is up to date in their IT skills. Developers love to learn new tricks, make sure you train them or allow time off for training.
  • Enjoyable work - developers like to do important tasks that involve use of their technical skills. The dislike producing low quality products. Make sure your developers are distracted as little as possible by people or administrative tasks.
  • Ability to have fulfilling family life - when rewarding developer remember that he would rather have time off than sit at the desk for 10 more hours.
• Other things that will make developers happier and thus more productive:
  • Flexible office hours - it is a great idea to let the programmers choose their office hours as people are most productive (and less sleep deprived) at different times of the day.
  • Private space, a room for every programmer is a good idea.
  • Good PC support, up to date hardware, easy access to all office supplies.
  • Easy access to newest reference books.
• In order for something to motivate an average developer it has to be logical - for example, a deadline that is not achievable when careful project planning is done will not motivate developers but their managers. Only a deadline that is achievable (but possibly hard to achieve) is going to motivate you development team.
• In order for your developers to stay at your company you need to reward them for their work frequently. Don't underestimate the power of non-monetary gifts. Team t-shirts and other small items are reminding developers just how much you appreciate their hard work.
• People by nature like to discover things, they like to travel and they perform better if they are part of a study. Take advantage of this natural tendency, also known as "Hawthorne effect". People do better if they know they are part of an experimental software group.
• Avoid these activities that kill morale - these are opposite to the factors that increase morale.
  • Don't lie to your staff - fake deadlines are easy to spot.
  • Too much pressure is exactly as it sounds, too much. Your stuff will loose their ability to work efficiently.
  • Make sure that managers which don't know too much about technology stay away from your stuff. This also applies to sales and marketing department members - their role in the company doesn't include developer harassment.
  • All decisions that effect developers should be discussed with them. It is a bad idea to make decisions for your staff, since they no longer feel that they are part of the team. They are no longer on a mission but are experiencing hardship.

Part 12: Teamwork

• Team is made up of up to 10 people that agree on common goal and way to reach this goal. People that make software teams also have complementary IT skills.
• Performance differences between teams are almost as great as performance differences between individual developers.
• All high performing teams have common characteristics which are listed underneath:
  • All team members share the same goal, this team mission is well understood by every team member.
  • All team members share the way team goal is to be achieved.
  • Teams are separate entities, there is a sense of pride of being in one team versus another, competitiveness vs. other teams. Members of a team are no longer individuals - they are team members. Team success is much more important than individual success.
  • Every team member is an expert in his or her area. Team has to have balanced technical skills to be effective, no amount of work is going to push a project if team members simply don't know how to do push. Non-technical, soft skills are also needed in support roles.
  • Every team member trusts and respect every other team member.
  • Working with the rest of the team is very enjoyable for every team member.
  • Team members communicate well with every other team member, sometimes using team exclusive terminology.
• The following is a list of what can go wrong with a team in addition to negative of characteristics listed as good team properties.
  • People that are "members" of a team but chose to sabotage team efforts. These are problem employees and they should be removed from the team as fast as possible. Ignorant and secretive as to their work people have no place on a development team.
  • Factors that prevent teams from doing their job, like inappropriate management involvement.
  • As with individual developers, teams need to be recognized for their hard work.
  • The whole team shares successes, but as in a marriage, the whole team shares failures as well. Everyone is contributes to team success, thus everyone is accountable for team mishaps.
• Software managers should be concerned with clearing development roadblocks and allow the team to be more efficient. His or her role is that of a supporter, product could be developed without the manager but not without the developers. Managers should deal with non-technical issues.
• Technical leads are programmers with extra responsibility. They are responsible for technical aspects, like design, on a single team. They should leave as much non-technical work as possible to managers.
• It is OK to let teams sit idle for short period of time - it is much more expensive to build new team from scratch later on.
• Teams, as individual developers, should be kept away from company "politics".
• As with lifecycle models, there is no one perfect team structure. Team structure is the way team members are organized inside the team.
• There are three main team types, you choose a type based on project objective. As there is no best lifecycle methodology, there is no best team structure - it all depends on what you want to achieve.
• The following list outlines most common development team models:
  • Business team - most common in the industry due to its simplicity. This team has a lead developer with a group of developers of equal standing. Lead developer is usually the team contact person for the management and the developer who has the last say in technical disputes. This team structure is very flexible, it can work on any project, but its flexibility comes at the price of not being the best model for any particular problem.
  • Surgeon and nurses team - in this team bulk of design and code is done by a star developer. Other team members specialize in different areas of surgeon support. This model is well suited to projects that either have a good plan or need creative mind.
  • Skunk works - if your goals are extraordinary you need to loosen usual rules. A Skunk Works is often a small (in order to reduce communications overhead) team that develops something in a short time with minimal management constraints. Can be used to spearhead product design that later will be developed according to the usual rules. Can be used for secret projects - great for research projects.
  • Feature selection team - has representative from every party concerned, ie development, management, marketing, quality assurance etc. Good for problem solving areas as it has great decision power due to representation from the whole company.
  • SWAT/ Commando teams - used for emergencies made of highly trained individuals that form a permanent team structure. All members are trained in specific area of development, for example in ASP.NET. Used for both problems situations and where there is a need to quickly execute a plan.
  • Firefighter team - this team can be assembled and put into action at moments notice, at any time. Used for emergencies - problem resolution.
  • Theater - developers play different roles with the manager acting as the producer. Roles developers are assigned don't change. Good for multimedia projects which have to do a lot with art.
• Team models are applied to solve three main types of tasks:
  • Specific problem resolution
  • Research and development
  • Plan centered execution
• On every team there should be a person responsible for the conceptual integrity - a team leader.
• On large teams communication overhead can slow development. Break large teams into smaller ones, of no more than 8-10 people each - form a hierarchy. It's a good idea to use military as the model, where squad leader is the person that has the most people under him (8-9). Officers have at 3-4 people they directly command.

Part 13: Feature-set control

• One of the most common reasons why planned schedules don't reflect real schedules is the problem of creeping project requirements.
• You need to take control of the feature set:
  • Use minimal documentation - avoid wasting time on non-essential document preparation, prevent documents from becoming obsolete due to problems with their maintenance, constrained design - luck of flexibility that will allow developers to create features faster.
    • Make a short introductory project paper, about 5 to 10 pages in length.
    • Common vision specification - one time only approximation.
    • Create manual that will serve as a specification.
    • Create visual story book - pictures are worth 1000 words each.
    • Create project vision as to what is the overall mission/ goal.
    • Make sure you don't omit critical features.
    • Don't gold plate anything.
    • Be advised that minimal specification will limit your abilities to participate in parallel activities.
    • Remember that you should use minimal specification only when project allows for flexibility - your goal is to trade speed for some fuzziness in the overall design your team is going to use.
  • Remove and clean requirements - if something is not needed it can be removed, if it doesn't have to be coded and planned for then it doesn't require any effort. This is one of the best ways to shorten your schedule.
    • Remove what is not needed.
    • Simplify everything that is needed.
    • Use less ambitious options for most time expensive features.
  • Understand sources of changes and how to control them - note that developers, end-users and marketers will try to change the requirements. Avoid commitment to impossible goals, frequently proposed by people that want to create a "killer" application.
• You should not assume that there never will be any changes, or that you can prevent any change requests from occurring. Needs of your customers will dictate what you need to create. You don't want to produce a product that is inadequate due to your resistance to change.
• Control of requirements stability is important to overall success as one of the more critical mistakes that you can make is to assume that your requirements are stable while they are swinging back and forth.
  • Work on the requirements closely with the customers, use prototyping techniques, lifecycle processes that give a lot of feedback to the customer.
  • Provide cost and schedule estimate for every change - even small changes late in the project can have large cost.
  • Move features to the next version - quick release cycles help a lot.
  • Create a group of people responsible for change request processing - make sure process is not to bureaucratic.
  • Implement software development method of triage - where only the most important changes get to be implemented.

Part 13: Productivity tools

• Productivity tools help with development work, however, remember that they usually never help as much as marketing department of the company that produces (sells) them.
• Remember that every new tool and every new technique requires learning time. During training tools use might decrease development speed instead of increasing it. Without training in the usage of the new software your team might not be able to use it efficiently, negating all the gain that the tool would have brought with it in terms of time savings.
• No tool or technique will provide dramatic improvements when used alone - don't get fuelled by empty claims of software vendors.
• Tools are great at helping with tasks that computers were designed to simplify - for example, they can eliminate need to repeat any aspect of development work. Good HTML development environment will provide closing tags to all open tags entered by the developer.
• Higher level programming languages trade speed for decreased detail control. If you don't have tight specifications and are able to satisfy your customer with standard application look then savings will be noticeable.
• You may consider creation of a special team of experienced developers responsible for new tool acquisition. This team will analyze and suggest new tools.
• All software that you going to buy should not only satisfy your current needs, but also your needs in the foreseeable future (not too far away future - only the one you can see from planning).
• You should by software from reputable vendor of good quality (version 3 and above show that the "baby bugs" are mostly eradicated and that the vendor will be less likely to cancel further tool development work).
• Total payoff from the usage of a tool should be counted against the area the tool acts in. For example, if you switched from C to Visual Basic you should expect most savings in coding, less in design, none in testing.
• Savings in effort needed due to the use of a tool don't linearly correspond to savings in schedule.
• CASE tools are in most cases (except where high amount of database work is involved) high end diagram creation tools.
• Object oriented programming is great for reusability of code, however, it doesn't offer any improvements as far as ease of use is concerned. Contrary to popular claims, OO is not more natural way to program (if it was so natural we would all be great OO programmers - everyone knows that is a false statement).

Part 13: Project recovery

• The key to placing project under control is to go back to the basic ideas of software development.
• Don't rescue projects that are just having small problems. Through it might seem wise to try to cure the problem early on, before it develops into a full-grown disease. Rescue that is started to early will be seen in negative light by upper management, which will never see any problem with the project as it was. They will, however, see you, project manager as the one crying for help prematurely - whistle blower.
• When you want to regain control, don't shorten any development phases. If you do, you are loosing control over the project rather than gaining it (as you known less about what is going on).
• You need to be realistic as to what can be done, ask your team members what they can do. Developers will not commit to objectives that are out of their reach (they are too logical to do so).
• The following is a list of steps you should follow when you begin project rescue:
  • Find out what is going on in the project - make a quick reckon of project accomplishments so far and its goals.
  • Do anything in order to restore your teams morale and commitment to the project.
  • Remember that one of the classic mistakes that you can do is to add people to the project when it is in need of help, sometimes this can help - but it needs to be very well planned operation.
  • Make sure you eliminate as many classical development mistakes as possible.
  • Your developers task completion should be evaluated using binary system, either they done their task 100% or not (anything less than 100%).
  • Small milestones should be scheduled. Project and individual developer recalibration should be done on weekly basis.
  • Make sure project requirements don't change - you don't want to chase shadows. If possible, remove as many features as possible from project specification.
  • Remove broken parts of the code - re-write them if necessary