Author: Rob Broadhead

  • Using Milestones For Project Communication and Success

    Using Milestones For Project Communication and Success

    One of the important parts of tracking project progress is defining milestones.  These are points during the project where the required tasks and the goals for time meet.  It only makes sense that the definition of milestones and how they are treated are an important part of project success.

    Defining Milestones Simplified

    Although these steps in the definition process are necessary, that does not mean they have to be complex.  Every project is different, but I have found these guidelines useful.  In fact, I use them every time we need to craft milestones.

    1. Milestones must have a deliverable

    Defining a deliverable for a milestone is rarely a problem.  However, I have seen vague descriptions like “complete the application UI” as the total of the objective.  This description is a start, but not truly definable.  Nor is there a deliverable mentioned.  We have to be able to say a milestone is complete (or not) without ambiguity.  This example is improved by including a UI demo to be delivered as part of the objective.

    2. The deliverable must be visible to the customer

    This point is often an issue during a project.  There will be a step that includes securing the site or building a backend database.  Unfortunately, the implementation does not have a visible result. That is not okay.  Find a way to craft the deliverable so that the customer can see that progress has been made.  The progress may be a login screen tied to an ACL or the result of some select statements to show default data in a database.  When in doubt, modify the milestones, so the “invisible” work is part of visible steps.

    3. Provide a Method For Feedback

    Milestones are more than just getting work done.  They are also an opportunity to gather customer feedback.  Use the milestone deliverables as a way to verify the implementation is still on track with the vision and goals of the client.  This option helps deliver a successful project instead of just delivering a project.

    Defining Milestones For Success

    We have already alluded to milestones being about more than progress.  They can also be designed to improve the chances of a successful project.  As mentioned earlier, the first step is to ensure that customer feedback is part of delivering any milestone.  This goal can be achieved through regular demos and review sessions that coincide with milestone deliverables.  I find that presenting milestone deliverables in some way is useful for drawing out feedback as well as a sort of test of the deliverables.  That extra look over the deliverable can be a sanity check well also revealing gaps.

    Scheduling the milestones in a way to reduce risk is recommended.  When the milestones that have the most risk are tackled early in a project, it allows for the less risky steps to be used to make up time.  Of course, that is not always possible.  In most cases, the work on challenging items early in a project is a way to bring up estimation issues and slippage sooner.

    Defining Milestones in a Vacuum

    We are not always a part of the project definition.  Thus, we run into those projects that are ill-defined and yet, we want to be successful.  In these cases, I find it is best to break the work you control (or are assigned) into milestones.  Your position in the team may not allow for customer feedback as part of milestone delivery.  However, you can usually find someone to which the deliverable can be presented.  Every little bit helps.

    Even the largest projects can be broken down into smaller “sub-projects.”  This step is where milestones come into play.  Thus, an over-whelming or “impossible” task becomes more manageable.  Since there are so many ways projects can go wrong we need to use tools like milestones to improve our chances for success wherever possible.

  • The Importance of Communicating Status and Plans

    The Importance of Communicating Status and Plans

    One of the best ways to control project success is to meet or exceed expectations.  One of the best ways to understand and impact expectations is through regular status and review.  Therefore, status reporting habits are an excellent way to improve the chances of success for your project.

    A Failure of Communicating Status

    I had an experience that has made me a firm believer in providing my clients with a weekly status.  In this case, the problem came from a sub that I trusted, and a customer that was happy and trusting.  I would periodically touch base on progress and tasks.  I left things to run on their own as did the client.

    We had some communication issues that led to my sub doing more testing and rework than the customer desired.  This confusion would have been a small problem if caught early, but instead, it went on for weeks.  Thus, by the time the client saw a large number of hours on small numbers of tasks, it looked like they were getting over-billed.  In a sense, they were.  Therefore, we ended up eating a bunch of billed hours and rolled the sub off of the client.

    A weekly status of hours and work would have brought this issue to a head earlier.  That early catch would have been easy to correct and saved headaches on both sides.  This situation could have ended worse, but part of the reason I did not over-communicate was due to the great relationship I had with the client.

    A Lesson Learned

    I learned from this bad experience that communicating status is an important detail to address.  I now send a status each week to every client large and small.  Most status reports are one project and one page.  However, sometimes I go to multiple projects per client and multiple pages.  I may also append some pages of notes or deliverable recap to make it easy to link tasks to outcomes.The status I send is not very complicated.  I list what was done, roughly how many hours were spent on the tasks, and then estimates of tasks and time for the week ahead.

    The status report takes less than fifteen minutes to put together each week.  However, I did spend close to an hour creating a template that is easy to fill out and still looks pretty good. Thus, the time I invested has more than paid for itself over the last few years.

    The status I send is not very complicated.  I list what was done, roughly how many hours were spent on the tasks, and then estimates of tasks and time for the week ahead.  This takes maybe fifteen minutes to put together each week.  However, I did spend close to an hour creating a template that is easy to fill out and still looks pretty good. Thus, the time I invested has more than paid for itself over the last few years.

    Keep It Simple

    The art of making a weekly status valuable is in its brevity.  Keep to simple line items and maybe even a summary at the top.  Consider that a client will only read the first part of the status.  Anything below the fold may be missed.  In particular, this scanning of status will occur as they receive one week after week.  Yes, it is a little bit of a CYA, but the real goal of this is to make sure you are on the same page as your clients about work to be done and priorities.

    A weekly status call would be a good way to keep it simple, but I recommend a written version as well.  The report provides something for future reference by your client.  However, it also provides you a great checklist to make sure your tasks completed each week match what you said you would do.  Communicating status seems like something everyone knows and values, but it is easy to get away from the process.  Beware if you do.  The lack of communication can cost contracts, clients, or even reputation.

  • Contractors or Employees? Options for Growing Your Team

    Contractors or Employees? Options for Growing Your Team

    In building a team one of the first questions that need to be answered is whether you will use contractors or employees.  Although this decision may be dictated by circumstances, it is important to recognize the pros and cons of each.  In the spirit of full disclosure, I have been a contractor for most of the last decade.

    Let’s look at the positives of employees first

    Loyalty used to be a huge plus for employees, but that seems to be less a factor every year.  However, an employee does still improve the likelihood of team continuity.  Employees may leave your organization, but it is more likely that contractors will move on.  This can cause a drain of business-specific knowledge.  Consequently, employees are more likely to give a return on the investment of training them on your processes.

    An employee also provides more ability for you to impact their attitude.  Never discount the productivity that can come from a happy and motivated employee.  There are steps you can take to make contractors happy.  However, you will have much more at your disposal to keep and motivate an employee.

    Contractors will sometimes talk about a partnership with their customers.  This is a good attitude to have, but at the end of the day, an employee is more closely bound to a company.  Their future is tied to the company success in a more direct manner than any contractor.  This symbiotic relationship does not guarantee everyone works together.  There are always going to be politics and personalities that drive a team.  Nevertheless, employees are at least going to have some shared benefits to come from a successful company.

    Finally, contractors tend to be project focused.  Your company may hire contractors for the long-term, but most will come in, focus on a project, and then move on.  This works for turnkey projects.  However, it is not the most efficient way to build a living, growing solution.  There are always ideas during implementation that get set aside but are valuable in future releases.

    Contractors have a different set of positive attributes

    It may seem cold, but contractors are disposable.  The investment made in a contractor should always be smaller than an employee.  Training and benefits are worries of the vendor, not your company.  A contractor should be primarily a short-term resource and it is usually easy to end a contract.  In any case, you let contractors go, but have to fire employees.  This has a lower cost no matter how you slice it.

    A contractor brings a new set of skills and experience.  Employees will have shared experience over time.  That is a strength of building a team but can also lead to a form of tunnel vision.  A contractor will have a different set of experiences and often can bring a new set of skills to the team.  They also will be on the hook to keep their skills current and marketable.  This can be a way to improve the overall skills of the team without paying for more training.

    One of the biggest strengths of using contractors in my experience is the ability to flex up and down those resources.  It is almost always easier to find another contractor than it is to hire someone.  You can also reduce contractor headcount quickly and reduce costs during slow seasons of business.  In fact, this is my most recommended approach to software development.  I recommend and have followed the process of building a core team that is small.  Once the team is in place, use contractors to handle peak or high-need times.  This keeps overall costs and commitments low while still getting work done.