Managing a Project

Projects come in all shapes and sizes as do customers and teams.  So there is not a one size fits all playbook or secret to being successful. Some project teams and customers require super focused processes, others are able to be more ad hoc and iterative.  

To further complicate things project management is broadly categorized into two methodology camps:

• • Waterfall: The joint teams build a set of requirements and a project plan up front, go away for a period of time to do development, come back for review and testing and deploy.  This approach allows for you to know what you will end up with upfront, however sometimes by the time development is done it isn’t what you actually need.
  • Agile: The team define a core set of business objective, roadmap and in some cases high level design. Once that is complete they begin to build in “sprints” or mini-project lifecycles where development,testing, and release is done in each cycle. This is more iterative, and often leads to a product that more closely resembles what you actually need.

 

While there is a time and a place for each, in general Agile allows you to deliver a product more closely aligned with reality. However, for software development not done in house it is very difficult to procure true agile – procurement organizations don’t like to sign contracts where there is no discrete result.  As a result, many services organizations have morphed to a bit of a hybrid version, we’ll call it disciplined agile, that allows you to mix the best of each.  You contract for a high level of deliverables, a set of guiding assumptions and assumed effort and then once that is confirmed during a design phase the customer and vendor will embark on a series of sprints where story points, which define amount of effort per story (or requirement,) are used as currency to make decisions about what goes into a sprint.  The sprint velocity (average number of story points burned per sprint) allow you to plan out future releases more effectively.

 

As we mentioned agile is the more popular methodology in technology today. Cloud technologies are especially suited to a more iterative approach and as a result many customers think they are using agile methodologies.  When you get further into a project you find out that they are in fact using agile terms – scrum, sprint, stand ups – but they aren’t able to move as quickly as true agile might require. Typical sprints will take 2-4 weeks and many customers can’t turn around reviews and approvals that quickly.   This means it is important in the sales cycle to be realistic about the timelines and phasing you define.

 

The other area that is key is project documentation.  Waterfall tends to be heavily documented, and in truth people rarely read all the documentation provided.  It is important, however, to have project decisions and activities memorialized so the project status is key.

 

A good project status should be done regularly, be short enough to read in a minute or two, but complete enough to show weekly progress, budget, major risks identified or mitigated and upcoming activities / dependencies.  It is important to also make sure that you are soliciting feedback regularly from both the project team and the customer(internal or external.) Ask for real feedback, not just a thumbs up or down.

 

Meetings help with team communications, a combination of standup meetings and status meetings are often used.  Standups are typically very brief daily meetings where each participating team member provides updates on yesterday, plans for today and blockers. Status meetings are typically with a larger group of stakeholders, including the customer sponsor, and using content from the standups you discuss action plans for the week.  Lori Asburry is particularly adept at these and once delivered one in Haiku. (really, just listen to the podcast)

 

Finally, one question that often comes up is whether a customer needs a project manager from the vendor.  Unless you are expecting true staff augmentation where the customer owns all the risk of the deliverables and the team just operates within the customer’s process, timeline and budget then the answer is yes.  A full time PM may not be required, however you’ll benefit from having someone from the vendor managing budgets, dealing with signoffs and team logistics, planning tasks, deliverables and timelines.

 

Managing a project is combination of both project discipline and methodology and people management.