As anyone with even the slightest bit of experience in software development, even simple websites, delays and cost overruns are incredibly common. A commonly cited statistic is that 85% of IT projects overrun their budget!While I would never claim that I can lay out a bullet-proof project management methodology in a series of blog post, there are definitely some simple mistakes you can avoid that will dramatically reduce the risks of cost and budget overruns.With that in mind, I asked our team members here at GreyLoud, the Hong Kong based IT company what they thought the most common mistakes were that caused problems on IT projects. I have a very high opinion of our team, but I was truly surprised at how good the points were that they brought up from their own personal experiences. I also found that people from different roles in the development team provided very different, but equally important, perspectives on what they thought the were the most common problems.I decided that the advice they gave was so good that I would devote an entire blog post to each item. For each I have described the scenario, then offered practical steps on how to avoid the issue for both the client side (internal or external) as well as development team.
Given that the responsibility for delivering a successful project fall on the development team, I provide considerably more details in that section, including easy to follow instructions and processes that can be applied in any organization.
Without further ado I present:
Mistake # 1: Sourcing requirements, feedback, and approvals from a stakeholder who is not authorized to make a final decision (the project/product owner). In other words, not following a communication plan!
I received our first tip from our Ruby on Rails Engineer Anton. Simply put, make sure that anyone giving instructions, requirements, or feedback to the development team has been authorized to make a final decision on the topic.Imagine this scenario: A junior member of the marketing team requests changes to the design of their new website. The dev team, not knowing that this employee is not actually the person responsible for managing the website design, rebuilds the website based on the what they have been told.
When the CEO sees the result, they are shocked and angry to see that the website is completely different than what they asked for! The CEO is angry because of all the wasted time and money, and the dev team is frustrated and demoralized because they worked very hard on something that wasn't needed!
Everyone realizes that this mistake could have easily been avoided with a little more attention to managing communications.
Managing communications as a client:
Make sure that you have a clear chain of command established with your project team, and make it clear to them that they should never under any circumstances give advice, instructions, or approvals unless it has been decided ahead of time they that team member is authorized to do so. Even if a member of your team is a subject matter expert in any given field, such as design, establish a process where that person provides their input to your project owner who will then pass it to your development team. Like many SDLC best practices, it may seem like an extra step, but this is one of those situations where an ounce of prevention is worth a pound of cure.Also, make it clear to your project manager on the dev team or IT contractor that only certain people are allowed to provide approvals and feedback, and that input from other team members must be approved by an authorized individual before any work begins.
Lastly, if you feel your project requirements are large or complex, ensure that your development partner creates and enforces a formal Communication Management Plan, which I describe in more detail in the section below.
Managing communications as a member of the project team:
First of all, make sure to specify in your contract or project charter that the client or project owner must designate one (and only 1) person to represent them that your team can rely on for feedback and approvals.
Under absolutely no circumstances should anyone on the software development team accept feedback from any other person without prior authorization from both the project manager and project owner.
For large projects with many stakeholders, always invest in creating a formal Project Communication Plan.
This document will describe how messages and critical information will travel between various stakeholders and members of the project team. This is done by first describing the objectives of all information passed between team members. Some examples of communication objectives are:
- Collecting feedback from users or customers to improve a product
- Eliciting business requirements from a Product Owner
- Translating business requirements into technical requirements and passing them to the development team
- Getting approval from a Product Owner on work product (such as a design concept)
Next, define the roles that each person will play, then define the type and purpose of the information that each person will need to receive and disseminate.
Generally speaking, stakeholders and team members will fit into one of these categories:
Client side project roles:
- Project Owner - Assembles the team, manages all stakeholders, and approves work product.
- Stakeholder - Not explicitly responsible for the project, but a person who will be affected by the project, such as a future user of the system. This person will give the BA information on what they need from the system.
- Subject Matter Expert - Aids Business Analyst in creating a software solution by giving insight into the nature of the business problem being solved, or the behavioral habits of potential users.
Development team roles:
- Project Manager - Creates schedules, directly manages activities of the development team, passes feedback and updates from the project team to Project Owner/Committee.
- Business Analyst - Elicits requirements from the internal or external client stakeholders. Depending on the SDLC methodology used, will create development documents such as features lists, user stories, or interactive prototypes.
- Development Team Member - Turns design materials such as mockups and user stories into functioning software based to the specifications provided. Covers several jobs such as software engineer, designer, QA specialist.
Next, define the acceptable Communication Tools and Methods
First, define which platforms or mediums you will use to communicate information. At GreyLoud we use the popular chat tool Slack for the majority of our internal communication, as well as communication with our customers. For telepresence and remote meetings, we find that Google's free voice and audio chat tool Hangouts is a great fit because it integrates seamlessly with Google Calendar and because it doesn't require users to download any special software to use.
Sometimes you may have to adjust the tools your team would normally use due to internal protocols at you client, especially if they are a large company with a restrictive IT and/or regulatory compliance environment.
Additionally, you should define the documents that will be created to fulfill specific communication objectives such as:
- Meeting summaries
- Status reports
- Formal presentations
- User and Technical Manuals
Also, specific types of meetings such as:
- Requirements Workshops
- Software Demonstrations
- Scrum Stand-ups
- Scrum Retrospectives
At this stage you are should also be preparing your project plan, so be sure to note major communication items such as the kick off meeting, milestone reports, test cases etc. One way to do this is to create a communication matrix and attach it as an appendix to the project plan:
In the case of a large project team with a defined hierarchy or many actively involved stakeholders, it is wise to create a formal flowchart of communication and approvals that will make the communication process easier to understand for all involved.
The Last Mile: Creating the Project Communication Action Pan
In the final step, we will create a formalized document of all communication items in the project plan in the form of a Project Communication Action Plan. This is an expanded and detailed version of the communication matrix that includes all major communication items with the following details:
- Team-member or stakeholder (who?)
- Topic or content (what?)
- Who is responsible for the item (from whom?)
- Estimated date or frequency (when?)
- Delivery method or medium (how?)
- Status (incomplete/rejected/accepted)
- Additional information or comments (purpose, notes on content requirements, etc)
This sound like a lot of work, but lucky for you, we have included templates of all required documents of the Project Communication and much much more in our Project Plan Readiness Pack. This pack includes templates for all the major documents and information you need to assemble to drastically improve your odds of executing a successful software project.
Even if you plan on working with an outside development team (like our excellent team here at GreyLoud) fill in gout these worksheets will save you a ton of time, headaches, and money by setting you up with everything you need start building your big idea.
