Category: Building Software

  • 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.

  • 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.

     

     

  • Finding A Balance in Choosing Your Technology Tools

    Finding A Balance in Choosing Your Technology Tools

    One of the challenges we face when building a new product is the selection of the technology.  Finding a balance between a homogeneous or mixed solution can be difficult.  On the one hand, a single vendor is easier to work with.  However, on the contrary, you want to avoid lock-in, and single vendor solutions often lack the features of one built using multiple tools.

    All-In-One Solutions

    In my experience, a single technology solution almost never works for custom solutions.  Tools like Microsoft Access, FileMaker, and others that offer all-in-one solutions can be useful.  However, their use is limited, and customization can be painful, if not impossible.  That being said, simple applications like general accounting, address books, and catalogs are entirely possible with these tools.  These are solutions that need little customization and follow a sort of template solution.  These tools work, but often the end solution would have been cheaper to buy off the shelf.

    The cost of these solutions tends to be low as you can find resources that know the tool and have proven experience in it.  They know how to stay in the “safe” areas of customization and upgrades are often painless.

    Best-Of-Breed Solutions

    Another approach is to find the best tool for each feature or aspect of your solution.  This method often allows heavy customization and the ability to create your solution precisely.  However, there is a cost of integration.  The tools have to be made to work together.  Sometimes the “glue” used to put these disparate pieces together can be complicated to create and fragile once completed.  A change to any part of the solution could potentially bring down the system.  Upgrades become risky, and the pressure to leave things as they are can be enough to freeze the solution from enhancements and upgrades.

    The cost of these solutions can be very high.  In fact, this often is only a path open to enterprises and companies with a significant number of development resources.  It is very rare for one person to know more than a few of these sort of technologies.  Thus, there is often a need for at least a resource or two per technology.  Note that I said, “at least.”  Projects may require dozens of resources in each technology silo.  Keeping everyone busy during implementation requires substantial planning.  Therefore these projects can be challenging to manage.

    Finding The Sweet Spot

    There are more than two ways to view this problem.  So let’s look at the middle road.  Tools rarely are limited to a particular solution.  Thus, they will have strengths that can be used to solve other problems.  For example, a database can include business logic.  However, the front-end or User Interface tools can perform some as well.  Neither of these tools is likely to be the best way to implement business logic.  Nevertheless, it is possible.

    The key to selecting your technology stack is to find the best tools for your most significant problems.  These are the uses that will occur most often in your solution and have the highest impact for the customer.  To put this simply, make sure your key selling points are the features that work the best.  Likewise, these areas of focus should be the most stable, scalable, and easy to maintain.  You are not likely to spend enough time on ancillary features to focus on those solutions.

    Not Too Much and Not Too Little

    A single technology is rarely going to cover all of your needs.  However, a technology stack of three or four tools in tandem is very common.  This stacks can cover a lot of solutions without having to break the bank finding implementation resources.  When you use your technology choices in moderation it can keep costs down while still providing a complete solution.  It is a win-win for the company and the customer.