Change by any means is difficult, time-consuming and costly when applied to any organization. Altering the status quo takes a lot of effort, conversation, convincing, negotiation, influencing and when all those items are overcome the change might still fail and the old ways returns. However, I think change needs to be handled in a very systematic and pragmatic way. By making small changes, incremental steps and targeting the proper audience in the beginning adoption of a new methodology can be possible. The change I’m talking about in this case is embracing a Project Management methodology in the workplace.
First of all I don’t think it’s a viable move to shift an entire organization’s project development policy from something (not project management style) to Project Management style of producing services and products. A few of the ways to convince upper management and stakeholders to accept this practice is by selecting a project that might not be mission critical, independent and isolated project from the main business needs. I say this because it will allow the project and the process to grow organically within the team or business area without the cloud of other projects dependence over it and vice-versa. Regardless if it’s a success or a failure the Project Management process that was utilized during development can stand on its own merit.
I will point out two reasons for implementing a Project Management style in the workplace. The first is maximum effectiveness of planning and control. While it is hard to predict the success of any given project (because project managers are not soothsayers); you can improve the chances of success by employing a Project Management method. This is due to the fact that the PM guidelines allow you to address many important aspects of a project early in development: scope, time, cost and quality. Another critical characteristic of Project Management is it provides a structured approach to approaching, handling, and maintaining of projects. The advantages of a controlled process are it affords the stakeholders a well define structure of authority and responsibility. This method is not limited to the tech industries but can be practiced in various businesses. A few more added benefits is it improves the chance of meeting schedule deadlines, budget constraints and quality milestones while mitigating risks.
First of all I want to be clear in my opinion that making mistakes is part of product and/or service development. The majority of the greatest products and services serving mankind today were iterated through several mistakes and false starts and through mistakes we learn from it and build upon it. What I want to discuss and bring attention to are making those huge mistakes development teams make that generate zero profitability and possibly company losses.
Another disclaimer I want to be clear about is I am not a Project Manager but I have worked in many projects as a key stakeholder and have worked with several Project Managers in the past that I can speak for mistakes a project team and team members make that have huge negative results on a project. At the forefront of mistakes is the assumed expectation that each member in the team having a clear understanding of any given requirement. From my years of experience what is clear to someone may not be clear to another person or maybe interpreted incorrectly by another team member. The best approach I can offer about this issue is to make prototypes and story-boarding out certain scenarios and iterating through designs and getting everyone to sign off at each design milestone. Another issue that projects cannot live without is feature creep or scope creep. Personally, there is no way to avoid scope creep and I think as a development team, we need to embrace it. Scope creeps are bound to happen because at the start of the project only the bare bone foundation/requirement is known. Only through a series of iterated product development will the final and true idea will be revealed and scope creeps allows this to come to fruition. The only way to respond to scope creep is by adding it to the triple constraint and accounting for it in the project schedule.
From my experiences more projects are slowed and/or failed due to unclear requirements and unplanned scope creeps but these mistakes can all be nullified if we plan accordingly and do our due diligence.
Top 10 Mistakes Project Managers Make
Team Gantt: 10 Red Flags on Project Management
When projects initially start very few people think about the risk involved at the onset of development and perhaps those few individuals that do stress the importance of risk management do so because of past experiences and from being exposed to lessons learned reports. In the beginning of projects, the primary stakeholders are focused on the triple constraint of the product; the scope, time, and cost. Teams concentrate their full attention on delivering the best products/service to the consumer or customers. However, it’s very important to include risk management in the beginning of projects and not just at the tail end of development. The significance will have a great impact on the triple constraint because it allows for a smooth and effective communication between project managers, team members and key stakeholders. It also helps in creating safeguards on the project in the event that the worst case scenario occurs and it gives the team ample amount of time to provide a mitigating course of action.
There are a few ways to identify and mitigate risk and the first would be to enforce the idea of having specific deliverables at any given date. If the scope of the deliverable is too vague, it means that the project needs to be broken down into smaller items. Creating a work breakdown structure (WBS) can help with this practice. Another issue that most teams do not consider as a tool for risk management is communication. During team meetings, risk discussion is usually placed at the end of a meeting but this shows the priority it occupies in the project. Reviewing risks should be at the top of the meeting agenda and should be the default topic of any meetings. Another essential tip would be to discuss lessons learned which can help in identify bottlenecks that could again occur on the current project; an example would be budgeting and staffing.
Risk management should be at the top of any project cycle and discussion in order to stay within the triple constraint boundaries and deliver a quality product/service to the consumer/customers. Identifying and acknowledging the existence of a particular risk and having control systems to help mitigate the impact and prevention will go a long ways in minimizing risk.
In the past a project was deemed successful if it remained within the guidelines of the triple constraint of project management. The triple constraint of scope, time, and cost is still considered by many to be the de facto method to defining and measuring projects but in recent years several organizations including the Projectize Group have made discoveries that more project stakeholders are claiming other elements are playing a key part in a project’s success. In my view, the triple constraint has always been the ‘insider’ method of evaluating projects. In today’s organizations there are many metrics in calculating a project’s conclusion.
Claiming a project was/is successful is subjective and it depends on whose view is taken into account. If a project has multiple development stages, a particular team that belongs to a specific stage could declare the project productive if that particular team was able to meet and/or exceed its requirements. On the other hand, a customer could respond to a product as a total failure because despite the firm’s appropriate product release it was not what the customer expected and/or need.
Therefore, an important aspect of evaluating successful products is customer/end-user adoption and response. Another important aspect which contributes to a project’s success is stakeholder satisfaction. Stakeholder satisfaction is critical because it permits the shared vision and goal to come to fruition. When I discuss stakeholders I extend that definition to the outliers but not necessarily the general public; at my company when we get the critical stakeholders to buy into the project and move the project into various stages we not only get the feedback from the immediate team members but also the entire studio as a whole. This creates higher visibility to a design product which allows it go through several iterations before it goes to the public.
The two ideas above are just a couple of many more essential items which I believe can greatly enhance the chance of project success.
Measuring Project Success