If you're new here, you may want to subscribe to our RSS feed. Thanks for visiting!

Let’s face it, a lot of people in the business world today do a great job delivering results for their Clients but many hit a wall when it comes to scalability. The issue is simple… there are only 24 hours in a day and of those hours, only 4 during which one can really be productive. Delegation is a must if you want to get ahead and actually assume the role of manager rather than coordinator or key account manager.

Most of us never really learned how to delegate effectively and thus, we control way too much rather than teaching, coaching and inspiring our staff to perform at the same level as we perform for our Clients each day. There is no magic pill here, just a simple process to get you started and some best practices that we picked up along the way.

It all starts with hiring ‘A’ players and giving them both the authority and ability to perform their jobs and reach mutually agreeable objectives but, before I get ahead of myself… let’s start with an example of the viscous cycle.

THE SUPERVISOR’S LAMENT:
“I don’t have enough time to do everything that needs to be done!”

There are really only four options:

• Don’t do some of the things
• Make the day longer!
• Use the time available more effectively.
• Delegate some of it.

Clearly the best option above is to delegate some of the tasks but how do you delegate effectively? Let’s explore a few of the barriers to effective delegation first.

BARRIERS TO DELEGATION:

• I haven’t got the time (It will take longer to explain it than to do it
 myself)

• I lack confidence in my staff (They won’t do it properly/on time
- I can do it better myself)

• I’m the supervisor so I’m responsible(People expect me to know the answers/get the
  job done)

• I’m afraid (I’ll impose on others
- I’ll be disliked/resented
- They’ll be after my job
- I won’t be needed any more)

• I don’t know how to delegate

Here’s a little tip:
YOU CAN DELEGATE AUTHORITY BUT YOU CAN NEVER DELEGATE RESPONSIBILITY

So that we are all on the same page… let’s define the word
DELEGATION:
DEFINITION:

“Achieving results, by empowering and motivating others to carry out, to an agreed level of performance, tasks for which you are ultimately responsible.”

Please read and re-read the definition and commit it to memory. It will surely be handy to remember as you embark on this journey ;-)

If you invest time in Coaching your staff, they will likely become more competent and be able to take more off your shoulders. In this way the vicious cycle can be broken.
Coaching is a short term investment for the long term gains of improved performance; more independent and capable staff; and more time for you to concentrate on your role as supervisor.

REASONS FOR OVER/UNDER DELEGATING
Over Delegation

When tasks are delegated which fall within the area of ‘supervisory tasks’, this is known as over delegation.  Normally this would be considered to be an unacceptable practice, although there are certain circumstances under which delegation of these tasks would be acceptable.
Unacceptable reasons would include that the supervisor:
Dislikes the task
Is too lazy to do the task
Delegates to prove authority
Thinks everything should be delegated.
Some acceptable reasons would be:
Training/Coaching: where the task is normally done by the supervisor, but is delegated as part of a training session.
Succession planning: where an individual has been identified for potential promotion, or to deputize in the absence of the supervisor, certain tasks may be delegated which would normally be done by the supervisor.

EFFECTS OF OVER OR UNDER DELEGATING
The effects on the team leader who delegates too much, or too little are:
Too much:

• Causes resentment
• Loses respect
• Loses touch, and maybe loses control

Too little:

• Is overworked
• Has no time for planning
• Makes no provision for work being done in his absence
• Makes no provision for work being done in his absence
• Is despised by the team
• Is taken advantage of by the team

The effects on the team when the leader delegates too much or too little are:
Too much:

• Team is overworked and inefficient
• Team is prone to making mistakes
• Team resents the leader
• Staff turnover is high

Too little:

• Individuals don’t develop
• Motivation is low
• Team becomes complacent
• Team feels insecure

So… what can you do?

Here are 3 helpful tips from our manual on best practices on the process of effective delegation – they have worked beautifully with several of our Clients over the past decade and I hope that you get similar results. If you need some help implementing the following, just drop us a line.

THE 10 COMMANDMENTS OF DELEGATION

1. Choose the right person
2. ‘Sel’egate
   • WIIFM
   • IMPORTANCE
3. Coach
4. Specify results
5. Talk it through
   • How?
   • Action Plan
   • Deadlines
6. Never tell when you can ask
7. Give authority
8. Monitor implementation
9. Regular review/feedback
1
10. Support
11. TRUST THEM!

The Delegation Process
(Some Key Points in a bit more detail)

1. Deciding what to delegate = planning
   • Examine your own work and decide what can be delegated.
   • Plan to delegate now, do not wait for a crisis.
   • Decide the outcomes to be achieved, not the activities involved.
   • Plan the limits of the task, resources and time required.
   • Think about the criteria for measurement and control.
   • Decide on the person.
   • Think about what support the person will need.
2. Selling
   • Decide how to ‘sell’ it to the person involved
   • Ensure initial briefing is clear
   • Invest time in the briefing
   • check understanding and
   • choose  the time and place carefully
3. Their Plan of Action
   • Ask what they plan to do and how they plan to do it.
   • Ask about the timetable and what control check they will use.
   • Agree the reporting back method and the frequency.
4. Implement and never tell what you can ask
   • When you spot a problem, or potential problem, and they do not, ask questions.
   • When things go wrong, ask questions.  Let them solve the problem with your support.
   • Do not take the task back, unless the circumstances are exceptional.
   • Remember your responsibilities and use mistakes to learn and to plan for the future.
   • Inform others what you have delegated and to whom.
5. Follow up and …
   • Carry out the agreed reporting procedures.
   • Encourage and give credit for good performance.
   • Trust them.

My favorite delegation acronym is SMART, or better still, SMARTER. It’s a quick checklist for effective delegation and it’s more than 50 years old – it goes like this:

Delegated tasks must be:
•    Specific
•    Measurable
•    Agreed
•    Realistic
•    Timebound
•    Ethical
•    Recorded

In a nutshell… that’s all you really need to get started with delegation. If you have questions or comments, please feel free to share your thoughts with us – we’d love to hear from you.

Defining a budget for software development projects is something of an art form. Most cost projection tasks are the result of Client requirements, guesswork, gut feel and estimations that have little bearing on reality. Our Clients demand fair prices and solid proposals that they can go to their boss with for signature knowing that a reliable partner is standing by, waiting for the green light. These proposals need to be based on realistic estimations of our costs and our risks for delivering the level of quality that our Clients desire at a rate they can afford and in a time period that they want. Not many people are willing to discuss the topic but, the fact is, it has become a real challenge to deliver both a competitive quote and high quality result for Clients this past decade. The primary reason seems to be a lack of serious, responsible, dedicated and reliable individuals that are skilled in providing services on time, on budget and at the highest level of quality. One of our good fortunes is to have a strong team of A players already on board but a key component to delivering results that make our Clients happy is to deliver within 5% of our estimate.

Since hourly rates for coding, additional costs for rapid development and pricing of tools and other resources can fluctuate based on circumstances beyond our immediate control, we offer the following guidelines to help you create a consistent and justifiable budget that is also realistic.

The Basics
A budget is one of those pivotal tools that is used to make decisions in many areas of a company. When creating budgets please keep the GIGO rule in mind and input quality data as often as possible. For developers, budgets dictate the amount of time they can spend on specific areas of an application. For the project manager, it’s a baseline used to determine if the project is on track. For our Client, the budget correlates directly to the success of the effort. Regardless of circumstance, a number of basic philosophies can help your budgeting immensely by protecting it from subjective review. By understanding the basic concepts, and making sure that everyone involved understands them as well, you’ll be on the right track toward an accurate projection:

Identifying project costs 

When you’re identifying the costs of development, stay as close to reality as possible. Look at performance of the team members on past projects to get a feel for how long it will take them to program a given amount of code. Consult with your lead developer. Watch out for braggadocios estimates & consider multiplying your developer’s estimate by 3 to pad for your risk assessment stage. Remember to include costs for integration, meetings, security certificates, license fees, quality assurance, debugging, documentation, material costs, testing, deployment and planning time are all areas that need to be included in your estimate. Whether we will be billing our Client for these items or not, they are all valid and substantial expenses of a project. Including them will help you accurately measure the profitability of the solution down the road.

Be sure to itemize estimates for features that were not included in the specification. These are items that you suspect will be requested later on or those that would be beneficial to the final product. List these as options in your proposal and budget for them. Another good thing to up-sell is developer support time for about 60 days after launch. Often when a project is rolled out, support groups aren’t in place yet and thus many questions get deferred to the developers – plan for this eventuality.

Once you’ve got your costs outlined, it’s time to look at the probability of staying within those boundaries.

Risk
Risk assessment and assignment is very important to a successful budget. Without it, the crises that occur regularly and are an inherent part of any project, will affect your bottom line. Values in your estimate need to have this padding built in – it should not be considered a part of sales mark-up. Risk represents actual costs incurred over the course of development. Risk line items should include things like development team experience (or lack thereof), obscurity (supportability) of the technology used, planning time shortages, number of development teams, location of development teams, number of modular components, proximity and availability of the project driver, product dependencies such as databases or third-party software, server side technology, hosting configurations (cloud etc) and any unknowns.

Once you’ve determined your risk items, assign a scope and percentage to each. For example, if one part of your application is to be built in C and another in PHP, and your team consists mostly of C programmers, the PHP component may have a higher risk assignment under the ‘developer experience’ line item. The percent assigned should be applied only to the relevant portion of the project.

All projects have a certain amount of risk involved that can be attributed to human nature. People get sick, take vacation, disappear without notice etc. No one is an expert in everything. I always assign a percentage risk to this area – in addition to other considerations. Here is a sample of how we assess risk: An average 10-developer, 6-month project justifies a risk assessment of 7 percent of the total project costs. For longer projects and smaller teams, it will be higher; for shorter projects and larger teams, it will be lower. If your overall risk assessment is between 20 and 30 percent of the total project cost, you are within our operating norms.

Your actual total risk percentage will depend on your experience in evaluating the team and the pending effort. If, after calculating an estimate, your numbers are coming out too high, look at other projects delivered by your company. Did they actually fall within their budget? If not, your numbers may be justified. If so, you may be giving your team too little credit. Rectify project-to-project discrepancies before presenting your estimate to the project driver.

Regardless of how close you come to reality, a Client will be much happier if your project comes in below budget rather than over it; however, too high a risk value can create sticker shock, revealing inexperience and creating misgivings about your management abilities. By following the guidelines we’ve suggested and applying some common sense, you are more likely to deliver your upcoming projects on time, on budget and meeting your Client’s quality expectations. Remember that Time, Quality and Cost are interrelated. If you modify one of them, it will more than likely impact the others.

Yes, I’ve seen the future and it is a wave!
All you need is an hour and a half and you too will be able to peer into the crystal ball and see what’s coming down the pipes later this year and how this new technology from Google will impact our online lives in new and wonderful ways. Enjoy…

1. Why do we have to live with incompatible and inherently different types of communication — email versus chat, or conversations versus documents?
2. Could a single communications model span all or most of the systems in use on the web today, in one smooth continuum?
3. How simple could we make it?
4. What if we tried designing a communications system that took advantage of computers’ current abilities, rather than imitating non-electronic forms?

Google WAVE is the answer and if you’ve got an hour +++ and some refreshments, watch the video, give it some thought and then let us know what you might do with the wave… We’ve already started planning our collaborative extensions!

For those of you with less than an hour of available time and a bit of ADD, here is the 30′000 foot view:

A “wave” is equal parts conversation and document, where people can communicate and work together with richly formatted text, photos, videos, maps, and more.

Here’s how it works: In Google Wave you create a wave and add people to it. Everyone on your wave can use richly formatted text, photos, gadgets, and even feeds from other sources on the web. They can insert a reply or edit the wave directly. It’s concurrent rich-text editing, where you see on your screen nearly instantly what your fellow collaborators are typing in your wave. That means Google Wave is just as well suited for quick messages as for persistent content — it allows for both collaboration and communication. You can also use “playback” to rewind the wave and see how it evolved. That means that users of applications such as bug reporting, Customer support services, communication and decision making online just got a boost and companies that deliver collaboration platforms in this space are likely to get the boot.

Could Google Wave Redefine Email and Web Communication?  We think so but, let’s hear your thoughts.

The Problem

E-mail typically takes too long to respond to which results in continuous inbox overflow for those who receive a lot of it.

Given that our Time and Attention (two of our most valuable assets) are finite, we strive to find a way of responding to email effectively while managing our projects and building success stories for our Clients.

One Interesting Solution

Treat all email responses as we would SMS text messages and use a fixed number of characters per response – instead of counting characters in our emails, we count sentences. In addition, we do not check email more than 4 times each day.

To increase productivity and deliver the results that our Clients expect from us, we now spend less time checking email and have adopted the policy that all email responses regardless of recipient or subject will be five sentences or less.

At BoxOnline, we believe that how you spend your time and attention says a lot about who you are.