Live Earth was especially significant to me because I’ve be working on a SharePoint based web site for the launch on behalf of Conservation International.  My diligent software team and I spent many agonizing hours working around the clock to get the site up and running in a number of weeks for the launch data of 7/7/07, and the site was a great success.  This got me thinking, what is it I did to motivate my team into working into the twilight hours?  Where do other project managers go wrong under pressure?  I can only surmise, but the the following is a short list of some of the things a lead can do to motivate his/her team at crunch time….

Set Expectations – In my experience, both as a project lead and a developer, this is an area where many project managers go wrong.  If you expect your team to stay late and work overtime then you need to communicate this fact.   It is no good getting upset when employees go home at the regular time and complaining after the fact if you never set your expectations up front.

Get the Team Buy In - Every team member requires some form of motivation to drive them into working late.  For some it’s overtime pay, for others it is the thrill of seeing their hard earned effort go into production.  Either way, it is important that each member of the team have some level of responsibility and accountability on the project. No man is an island, and it is important to realize that large projects are only ever successful when effort is put in by the whole team.

Work The Hours - If you are asking your team to stay late and burn the late night oil then it is only right that you stay and work the hours with them.  This ensures you are available to handle any late night decisions, motivate employees suffering from lack of sleep, and keep the moral level high at all times.

Feed your Staff – Work goes much smoother when your team have full bellies, so if you have to dip into your pocket to buy pizza it is a small price to pay for the success of the project.

Reward Good Work – Honest sincere hard word deserves reward, so if your team pull out the stops and make a success then they should receive both recognition and reward for their work. 

Respect Personal Agendas – Once you ask your team to work beyond the regular 9-5 your are encroaching on their personal life.  Significant partners, children, and family members become concerned when they no longer get to see their loved ones for a few days.  So if members of your team need time to align their personal life cut them some slack.

Be Prepared to Roll Up Your Sleeves – During crunch time anything goes.  As project manager you are responsible for the success of the project, and if that means helping out with development or data entry then so be it.

Watch for Burn Out – So you’ve motivated your team to work late, only a little too much, to the point that one of your team members is looking worse for wear and needs to rest.  Do not be afraid to enforce sending someone home or at least taking a break – happy alert team members make for a successful project. 

http://lifehacker.com/software/let.s-touch-base/the-cubicle-warriors-guide-to-office-jargon-265894.php

How many of these have you used or heard used on you? [;)]

Microsoft Exchange 2007 – Yes, I hear the groans, but before I receive the comments about rigid IT departments who break out into a rash with the mere mention of Microsoft Exchange, let me tell you why the latest version – Exchange 2007 – is so productive. No matter what anyone says, I refuse to believe that any other mail server is as feature rich as Exchange. Taking aside the fact that Exchange is only happy when tied at the hip with Active Directory, in my opinion it is hands down the best messaging platform. Exchange has provided Outlook Web Access since version 2000, and the newest version still provides the same rich AJAX-like-user interface (introduced long before AJAX was a common term) to emulate the rich client version in a web browser. The new version integrates with SharePoint, allowing me to access my document libraries from anywhere on the Internet. Since version 2003, Exchange has supported MAPI over HTTP, and because my employer is nice, I am able to access my mailbox, calendar, and tasks using Outlook on my work laptop at home, as if I never left the office. Finally, my favorite part about Exchange – I can synchronize with my Windows mobile device, so can receive push email, calendar and tasks whilst on the road – how nice is that?

Outlook 2007 – I cannot talk about Exchange without mentioning its partner in crime – Outlook. Once again, find me an email client that can do half of what Outlook can (Outlook Express does not count because it is technically Outlook on a diet). I mentioned MAPI over HTTP above, which I use constantly when away from the office. 2007 includes an RSS feed aggregator, and like OWA, Outlook 2007 now connects with SharePoint to access document libraries, task lists and calendars. If you are an SMS hound, you can also send and receive SMS messages using the Outlook Mobile Services. Personally, I think the Internet Calendars feature is a lifesaver – I can access my personal Google calendars and overlay my off work schedule with my daytime schedule to see what the week has in store.

Windows Mobile – My Pocket PC phone combo (HTC PPC 6700) cost me a chunk of change when I brought it, but almost a year later, I never regret my decision. I cannot count the number of times I have been away from my computer and needing to get access to important information in an email, calendar information, or contact information. I think of my PPC as an extension to the office –the other day I was stuck in traffic on the way to a client meeting. So, I called my boss for my client’s telephone number, so I could inform them I would be late, and he was able to email it to me without having to relay numbers over the phone.

Google Apps for Your Domain – For a while, I was hosting an Exchange server at home to look after my email, mainly because I wanted email at my own domain name and I could not stand the half-baked web clients offered by the cheapest hosting clients. Only problem was is that, although Exchange is very nice, it is a problem when something goes wrong. Not so long back, I remember pulling an all nighter trying to get my server back online after a disk crash. When I heard about GAFYD – free email hosting for your domain email, I decided to let Google take the responsibility of backing up my email and worrying about offline issues. As far as everyone else is concerned, nothing changed; they can still email me at the same robgarrett.com email address. However, I get the feature rich web client of Gmail to access my domain-hosted email. No more headaches if my broadband connection goes down, or concerns with hardware redundancy.

Google Calendar – My wife and I used Google calendar long before I switched to GAFYD, which also uses the same calendar engine. Google calendar provides me, and the family, with a nice UI for shared calendars, and because it is Google, I can search for any appointment in seconds. Prior to Google, my wife and I were in constant battle over miscommunication of appointments – paper calendars were lost, emails about upcoming appointments went astray, and I found out about most planned events on the evening before they happened. I guess you can say that Google saved my marriage.

Foldershare – There is nothing more frustrating than finding out that all-important file is on another PC and you forgot to copy the darn thing over before a big meeting. Fortunately, there is Foldershare. FS synchronizes files between multiple computers of your choice, and I use this application exclusively to manage access to my important files.

Groove 20007 – Much like Foldershare, Groove enabled me to synchronize my files with other computers and peers, only Groove has many additional features. For one, Groove permits collaboration against SharePoint document libraries. So, my peers and I can work on documents together and when ready I can synchronize the changes to our company SharePoint server for archival.

I could go on, many more products exist that enable me to shave vital minutes off my day, but the above list contains the main tenants. Between these applications, I can collaborate on work items, schedule appointments, stay in touch with the office, plan my weekends, and gain access to all information when working remote – pretty cool.

1. You meet with your boss every day (sometimes more than once) – in each meeting he or she will ask for a status update.
2. You are asked for delivery estimates for the same task more than once a week.
3. Tasks are issued in precise patronizing detail, and all too often verbally.
4. No matter how hard you work on a task, the result is never good enough for your boss.
5. You spend more time in meetings than actually implementing the solution.
6. You have a spare seat in your cube/office and your boss occupies it regularly.
7. When away from the office, your boss will call you every day to make sure you’re at work.
8. You receive calls from your boss on weekends/evenings and if you’re out sick.
9. Your boss has intricate knowledge of your current tasks, down to the level of nitty gritty implementation.
10. Your boss coaches you on the precise wording to say to another colleague when asking for something.
11. You feel stressed and exhausted before you have even begun implementation.
12. Use of headphones is impossible because you cannot complete a music track without interruption from your boss.
13. Bathroom breaks are monitored by your boss, if you take too long to shit he/she makes a remark.
14. You prefer to work outside office hours because you are more productive that way.
15. Your boss never goes on vacation for fear that the company will collapse in his/her absence.
16. When leaving the office for lunch you receive a call on your cell about work related issues.
17. Your boss is involved in technical decisions when his role is at a much higher level.
18. Your boss talks more than he/she listens.
19. You are provided with a company cell phone, pager, laptop, etc, and are expected to be on standby 24×7.
20. Working from home is strictly forbidden, even when it would be more profitable for the company.
21. Your boss has an opinion on your visual presentation, even when you meet the company dress code.
22. Meetings are scheduled with 5 minutes notice and sometimes at close of business.
23. Your boss eats his/her lunch at your desk.
24. Everything is an emergency and cannot wait.

I can think of a few more, but in an effort to keep this post short I’ll leave it at that. [;)]

Disclaimer: The above list was generated from past experience, and not necessarily reflective of my current employment.

Today’s post, titled “How to Drive Your People to Meet Customer Deadlines,” certainly is as witty as previous posts, but I have to raise an eyebrow on the suggested technique called “No Deadline Left Behind.”

The synopsis of “No Deadline Left Behind” is that managers need not accept constant delays and fake promises of delivery from worker bees (named Johnny in this case) if they deduct payment form the worker each time a project misses a deadline.

1. For instance, say you hire Johnny for $1000 to write a white paper for customer Craig. Craig needs it done 7 days.
2. If Johnny doesn’t get that paper to customer Craig in 7 days, you remove $200 — returning those Benjamins to customer Craig.
3. Now, if Johnny again misses it on the 8th day, you remove another $200. And, so on — until the sucker’s free to customer Craig.

Seems simple enough… if we lived in a dream world.  Yes sadly we live in a world where employees like to do as little for their money as possible (typically) and managers want to extract as much work out of their employees (typically) to meet the deadlines imposed by managers further up the chain, or by paying customers – it’s a broken equation, but what most expect from 5 days out of a 7 day week.

Personally, I think employees – let’s call them developers in my world – need to take more of a responsibility for project deadlines.  It is not acceptable to promise delivery by a certain date and then blatantly blow the deadline without some concrete evidence of some unforeseeable problem, or direction change by management or customer.

But what if you work for a manager who does not live in the real world?

I’ve lost count of the number of fellow employers who have said something like the following: 

“The project was doomed from the start, there was no way I was ever going to meet my deadline.”
“The customer changed their mind mind flow.”
“My boss would not leave me alone to complete the project.”

All of the above and more are signs that you work for a “bad planner,” and if you’re the employee charged with making the project work at a lower level then expect unreasonable deadline expectations, overtime, and hair pulling to make the project successful.

My immediate thought on “No Deadline Left Behind” is – why should the worker-bee take the hit for a missed deadline?  There’s an art into providing a perfect estimate of work, and many employees get it wrong (including myself occasionally), which is why it is the job of the project manager to establish reasonable and workable deadlines/estimates with each employee. Surely the project manager should be pitching in to the refund collection along with Johnny?  And what about upper management? Your boss’s, boss’s, boss’s boss is so far up the food chain that they cannot possibly be concerned with the finer points of implementation, and any small change made to the project for overall gain can have a huge ripple affect through the lower levels – should he/she take a hit when the project overruns?

I am not sure there is ever a right answer to the enterprise project paradigm, but I am quite sure that the extraction of money from workers for delays will only incur a decrease in motivation within the ranks and mental images of slave drivers with whips.

•    The project is the main concern – any manager who is not giving top priority to the project has another agenda.  Typically, the project manager is solely responsible for a failed project, but everyone on the team suffers in the long run. The client, the contractor company, middle management, and all the software engineers.  If all project decisions made are in the best interest of the project then the project is more likely to be a success.

•    Be free with information – Managers should never be “black hole” people when it comes down to important information about a project.  A good project manager should be able to share his/her information and be free from concern about reporting employees gaining power from increased knowledge.

•    Co-ordinate with staff – Along the lines of being free with information, every employee on the project should be aware of what their peers are doing.  In the case that one or more employees are out of commission, the project manager should be able to delegate responsibility of work to another member of staff.

•    Control the road map – As a manager, I would not run a project without a project plan any more than I would drive across the country without a road map.  The project plan is the living breathing core of any successful project, which evolves with the lifetime of the project.  Projects should never start without a baseline project plan and during the life of the project; the plan should always reflect the current progress and next steps in the project direction.

•    The client is always right… – within reason.  It is the job of a project manager to set the expectations of the client with regards to what work can be completed in a finite period of time with a set budget.  The project manager should never promise more than the development team can deliver, causing burnout.  On the other hand, it is important to provide the client with solutions to some of their requests, and good communication with the development team can assist in the creation of a good solution.

•    Never micro-manage – This is the sin of all manager tactics.  When you micro-manage your staff you’re affectively telling them that you do not trust their abilities.  Micro-management usually leads to frustrated team members, and the project manager looses respect of his/her peers.

•    The buck stops here – Some difficult decisions are sometimes called for in the lifetime of a project.  These decisions can be technical, staff related, or just about taking the next step in the project roadmap, but no matter what the quandary there needs to be a team member willing to make the hard decision.  It is usually the responsibility of the project manager to make these types of decisions.  Everyone on the team is entitled to an opinion (and should be asked), but once a decision has been reached everyone on the team should abide by it.  If things work out, great, but if not, the project manager is solely responsible for taking heat on the mistake.

•    You’re the leader, so lead – The development staff looks for a clear direction from an individual who can overview the whole project.  The project manager should be strong enough to drive the project according to the project plan.

•    Be a people person – Project management, and management as a whole, is not just about being in power and delegating work to other individuals.  A great project manager knows how to manage his/her people so that they are motivated, non-frustrated, and have a clear understanding of their role in the project.  Make no mistake, project management is not an easy job, and it is not a bolt on task to a regular developer role.  Management of staff and project can take a while to get right, and not everyone is cut out for the job.  Bottom line – if you want a managerial role, you need people skills.

It is a sad fact that the software IT industry is awash with many individuals
that claim to be expert developers in the field in which they practice, but in fact,
they lack the skills required for the simplest of software development
positions.  Often is the case that these individuals will appear to have
the necessary skills on paper to secure them a job on a development project and
the only thing to stand in their way is a good interview screening process. Therefore,
what can be done to avoid jeopardizing a project if, as a project manager, you
find yourself with a bad apple on the team?

• Recognizing a bad apple – Most managers can spot a duff developer on the team, however
  poor performing individuals can often go unnoticed on software development projects,
  especially large enterprise projects involving more than a handful of
  developers.  It is the responsibility of a good project manager to have an
  accurate understanding of every team members past and present performance
  metrics.  The typical approach taken by many project managers
  is to maintain a project plan containing project tasks assigned to
  each developer, along with original estimates and current percentage of work
  complete. Project planning tools, such as Microsoft Project, can provide project
  managers with an indication of where the bottlenecks exist in a project and
  which developers are failing to meet the quota. A good project manager should always maintain a history of all
  staff
  under his/her supervision, both for future performance reviews and for
  a
  comparison of previous accomplishments with the present.  Regular
  design and code reviews and peer-to-peer staff meetings can also
  indicate a problem brewing.

• Cauterize the wound -

  Once established that a developer is lacking performance on
  the team it is important to isolate them from any tasks deemed critical to the
  success of the project. The developer will work on less important tasks until
  the proof of increased performance and understanding of the more crucial tasks
  is evident. It is important not to chastise
  the developer for their poor performance at this stage. However, the developer should
  be aware of their failure to meet the project expectations.

• Establish a cause – There are many reasons why a team member may
  fail to meet required project expectations. Failure to complete one or many tasks in a
  designated time period is not necessary an indication that the individual is
  incompetent in their role. Other factors, such as lack of training for the task
  in hand, lack of motivation, failure to apply talent in the correct area, bad planning,
  or a long number of hours etc, can influence the ability in completing a task.
  External factors such as a stressful home life, lack of sleep, a difficult
  commute etc, are other reasons.The
  project manager should invite the developer to share an explanation of inability
  to complete tasks assigned before concluding lack of professionalism.

• Provide an opportunity to make amends
  - Once all external factors have been ruled out or addressed, the developer can show promise and future worth to the
  project when provided with an opportunity to gain the confidence of the
  project manager.  A good way to provide this opportunity is to
  assign an obtainable task, which both matches the skill set of the
  developer and occupies a short time period.  It is the duty of the
  project manager to monitor the task progress to determine if the
  developer is showing progress.  The project manager must define
  the expectations up front and the developer should be clear on what
  objectives they must meet to complete the task.  This
  “hand-holding” technique requires extra time from an otherwise busy
  project manager, but secures the project manager with an understanding
  of the ability of the developer before any drastic action is required.

• Cut your losses
  - If the developer continues to show little or no promise of becoming
  an asset to the project and continues to be a liability, the time has
  come to cut them loose.  It is a sad day when a project manager
  has to fire a member of his/her development staff, but necessary for
  the good of the project.  Stale developers that do not provide
  useful input to the project can drag a project and impede the efforts
  of other useful developers on the team.  Never terminate developer
  (or any other team member) for personal reasons.  Plenty of
  guidelines exist for terminating an employee.  In a future post, I
  list some of the ways to fire a member of staff, whilst retaining
  professionalism and avoiding uncomfortable conflict.

• Never Micro-manage – I once worked for a CEO who
  would meet with me 3-4 times a day for an hour or two at a time, when
  not in meetings he would come and watch me work in my office.  He
  could never understand why I had trouble-developing software. 
  Micro-management tells your staff that you do not trust them to do a
  god job; it also severely hinders progress with the constant
  interruption of workflow.

• Responsibility doesn’t roll down hill – Many
  managers believe in the tiered organizational structure: The CEO sits
  at the top, and then comes the upper management, project managers, and
  finally developers.  This concept usually dictates that the CEO
  and management level employees stipulate the work for the project
  managers and developers.  Project managers’ figure out the plan
  for the project and the developers construct it.  The only snag is
  that management typically does not have a faintest clue about what is
  involved with software development; they only understand business and
  money.  Likewise, developers do not always know about the latest
  business deals or the financial situation of the company to determine
  the best software to engineer.  It is the job of the project
  manager to sit in the middle, with knowledge of both sides, and
  determine how to make a product best using the talent of the developers
  whilst staying in budget and within time line.  To be affective in
  this position project manager should be prepared to listen to both
  sides.  Sadly, too many project managers shift the blame when it
  comes to responsibility, leaving the developers with the task of
  generating software in an unrealistic time with stupendous constraints,
  and limited understanding of the expected solution.

• Have a vision of the solution – Some
  would argue that that solution vision is the responsibility of the
  architect; others say it is up to the PM, in most cases these two roles
  are satisfied by the same person.  Whatever the situation the
  person whom delegates work to software developers should have an
  understanding of how the finished product should work.  Developers
  should not have to determine vision.  In most cases, will each
  developer have a different idea and over complicate the problem to make
  use of new technology.  This does not mean that the view of the
  developers should be discounted, just considered as a view, not relied
  upon.

• Getting requirements from management is like getting blood from a stone
  - Management (sometimes the client) won’t necessarily know what they
  want in a software product, just that it should do everything, continue
  to do everything in the future and cost relatively nothing.  The
  PM should work closely with management/client to establish a base set
  of requirements.  Requirements are the basis for software
  developers to perform their work and a necessity in any software
  development project.

• Be accountable
  - Most project managers have no issues holding a developer accountable
  for the estimates and work they provide.  Developers should expect
  no less from their PM.  A strong manager who comes through on
  promise, turns up to scheduled meetings, and takes responsibility for a
  late project or project gone bad will gain the most respect from his or
  her peers.

• Reward good work as well as reprimand for bad work
  - Software developers are people with feelings (rumor has it), they
  like to receive compliments.  Saying “well done” occasionally
  costs nothing, and will often inspire an individual to work just as
  hard on the next task or project.

• People have lives
  - It is a known fact that die-hard developers like to burn the midnight
  oil in front of a computer trying to solve a development problem. 
  Never exploit this fact.  Any developer that routinely works more
  than 50 hours every week will most likely burn out and end up leaving
  the project for another with less hours and more pay.  If a
  developer is asked to work a weekend or late evening once in a while he
  or she will most likely oblige, but, ask them to work late every night
  and every weekend (especially if no overtime exists)  and they’ll
  start resenting the fact that they have no free time for personal
  pursuits.

• Manage staff expertise -
  Developers come in all different flavors, some good, some bad and some
  extraordinarily brilliant (I will let you decide which I am).  The
  trick is to manage a development team and level expertise.  A team
  with one expert and remainder bad will result in the project failing
  because the expert will get tired of being a crutch for the poor
  performers.  On the other hand, a team consisting of only experts
  is a hindrance because no one wants to work on the mundane jobs. 
  The trick is to balance the team to utilize talent best, and match
  interest level.

• Have a plan – A
  good development plan (Gantt charts are best in my experience) will
  resolve any curiosity from developers.  Getting buy-in from all
  involved is important.  It is no good asking completion of
  software from developers if they do not believe in their ability to
  meet the objective.  Commitment upfront also makes it easy to
  consult a developer when they fail to meet a deadline.

• Stay in contact – Always aim to be reachable by
  your team and encourage them to do the same.  During development
  questions will arise, in which the answers are not always obvious from
  the requirements.  Developers should be able to get clarification
  on issues sooner rather than later to avoid developing unnecessary
  software.  Avoid calling team members outside of office hours
  unless the staff member has given permission to do so.

• Always be honest
  - Never keep your team in the dark, if there is important information
  in the company that affects the project or employment status, the team
  should know about it.  The exception to this rule is any
  information that requires clearance, is not project related, or
  divulging of information that would violate the employee/employer
  relationship agreement.

For the record: The above information is suggestive and is in no way a
bad reflection of my current project manager/employer’s abilities. The
information stipulated above is based on previous experience throughout
my software career.

I’ve been a developer on many a software project, been a project
leader and also provided consulting services. During each of these
roles I’ve had the pleasure of working with some talented individuals,
who have taught me a thing or two. I’ve also worked with some
dissimilar individuals who have caused a great deal of frustration in
my career, but never less I have learned from them also – how not to do
things.

I’ve listed some tips for getting ahead below. At first glimpse they
may appear obvious, but it’s surprising how many developers and project
managers do exactly the opposite of what I’ve listed.

• It’s a job not a hobby -
  It took me a long time to learn this valuable lesson. Like many other
  software developers, I have a passion for writing software. Over the
  years, since I started at a young age, my passion has brought me
  through college and into a career. I’d effectively hand crafted my
  career from a personal interest – bonus! However, I soon found out that
  writing software for an employer is radically different to throwing
  some code together in my spare time for the hell of it. Namely, my
  employer is spending large amounts of cash on my efforts, which means
  they have some say in how I write software. It’s quite amazing how
  software deadlines, dictation of technology tools, budgets and
  unrealistic time lines can really put a crimp on creativity. Before I
  knew it I was waking up and not liking the very thing that had kept me
  up enthralled to all hours of the night during college. When I
  complained of this problem one of my colleagues politely reminded me
  that this is “work” and why I’m getting paid. He suggested that I save
  the wild creativity to efforts outside of work.

• Process brings about order
  - Get used to process. Unless you’re working on a small project with a
  handful developers and the software is small-scale, it’s likely that
  your employer will want you to adhere to some soft of process. Process
  can range from simply documenting software design to a large software
  design methodology, such as CMM or RUP.
  Either way, you’re employer will most likely expect some sort sort of
  design documentation, work breakdown schedule and user manual.
  Software development is no longer just about throwing code into the
  machine and praying it’ll work – brush up on different methodologies,
  learn how to use tools like Microsoft Word and Microsoft Visio and ensure you can
  articulate thought well in grammar, not just code.

• The Boss is always right – seems like an obvious
  statement, right? This didn’t stop me becoming very frustrated with
  the CEO, of one of my employers, because he insisted on micromanaging the
  project, imposing unrealistic expectations on results and always
  looking for a cheap way around a problem, which usually ended up
  costing the company more money in the end. One day I woke up and
  decided to go along with all his decisions. I still offered my best
  advice in every situation, but no longer battled for my point when my
  advice was dismissed. As a result I was respected more, and when the
  project failed, as I predicted, the CEO took the wrap for the mistake.

•  Do whatever is asked of you by your superiors – There’s a fine line here between getting ahead and brown-nosing.
  When the Boss is looking for a volunteer to perform an extra task on
  the project do your best to sign up and complete the request. The aim
  here is recognition, you want your superior to associate you with
  reliability and the ability to get anything done. Once you succeed in
  this lesson your boss will start looking for you when he or she needs
  someone special they can depend on, this will later help you to gain
  promotion. Never go asking for extra duties, this would be classed as
  crossing the fine line I spoke of above.

• Always go the extra mile – The employees that are
  always remembered are those that stayed late to fix a problem in a time
  of crisis. Every job I’ve found myself in has involved at least one
  late night, and in some cases a round-the-clock effort. The reason for
  the crisis and need to stay late is irrelevant, you employer will soon
  forget the problem, once solved, but remember those that stayed to fix
  the mess. Even if you cannot assist in providing a solution to the
  problem, being around to provide moral support for those who can is a
  sure way to secure a position on the list of heroes.

• Never forget your peers – Whilst doing a good job of
  securing your position with your Boss be sure not to forget your peers.
  Your peers are the people that will stay late with you in a crisis,
  help share the burden of work, and be working along side you for every
  day in your career. Never climb the ladder of success at the expense of
  your peers, this can only lead to animosity and isolation from the
  group. Some organizations rate individuals based on recommendations
  from peers members of staff, others simply watch to see how well their
  employees work in a team. Either way, being a team player is very
  important, without a team there is no solution.

• Estimate conservatively – You’ve gone to the trouble of
  signing up extra tasks to impress your leader, but you fail to deliver
  on every task your assigned – not good. For you to get ahead in this
  field successfully you need to be known as an individual that
  accomplishes their goals. When asked for an estimate on how long it’ll
  take to complete a software task be sure to take into account: margin
  for error, testing time, documentation time and deployment time -
  writing the code is only half the battle. Always over estimate by at
  least 50% – you’ll be liked much more if you meet expectations.
  Some project managers will add extra margin to your estimate, others
  will assume you’ve over estimated and expect you to come in ahead of
  time, try to find out how your project manager leans and set estimates
  accordingly. On the rare occasion that your project manager sets
  impossible expectations, stick to your estimate and go on record with
  your assessment – do you best to meet the demands with what you have to
  work with.

• Worry about today, not tomorrow – Unless you’re tasked
  with future project predictions it is likely that the CEO or another
  individual high up in the food chain is responsible for planning where
  the project is going next. As a software developer or project manager
  your only concern is meeting the project objectives of the time. This
  objective might involve writing requirements for the client, or
  implementing the software, either way the road ahead has been laid for
  you, so there is no need to concern yourself with future endeavors.
  My friend and colleague gave me a great analogy for this, it went something like – “we’re
  all passengers on an airplane, we should enjoy the flight and not worry
  about the destination, the destination is unemployment“.

Thanks to Sashidhar Kokku for finding this gem.