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
Outsourcing can either be a positive, negative or both influences at any organizations. I have experienced both sides of the spectrum and I will share my thoughts and opinions about the matter in this blog. Personally, I believe outsourcing can be part of healthy growing organizations and we see it in the world today with so many of the Fortune 500 companies using outsourcing to develop, manufacturing products.
The advantages of outsourcing are fairly straightforward; it provides cost-reduction benefits, it can assist in faster project completion, outsourcing allows for a higher level of expertise in a team, and the flexibility of forming a dynamic team. Those are all great points and for the most part all those points do work in certain industry sectors, especially in the technology sectors. From my perspective and familiarity, outsourcing is a double-edge sword where it can be an incredible asset in one hand and a hindrance in another. I will discuss the disadvantages in the next paragraph but as a benefit with the right talent pool, meaning hiring a person with years of experience and understanding of the industry; the outsource talent can provide a great boost to the company’s bottom line and product throughput. I have witness first hand at how superb product testing and quality assurance testing can be with the appropriate talent pool from outside the company. Another gain that I have observed first-hand is through product development of outsourced teams. There have been numerous development teams that I have been involved with that have demonstrated an excellent understanding of the product, the targeted customer and the development process and some of those teams were outsourced. I think the main criteria in making sure outsourcing become a positive endeavor for a company is to understand the level of expertise the outsource team/individual is bringing to the organization.
The disadvantages of outsourcing and I can attest to a few of them myself are: coordination breakdowns between teams, loss of control over the project, conflict on interpersonal level between teams, and security issues. I could not state the positives of outsourcing without mentioning a few worthwhile negatives and from my experience the biggest hindrance was always the communication breakdown. Whether it was the language barrier issue or the time difference; communication played a huge role in delayed responses, feedbacks and or product design interpretation. Projects can often times become delayed because of the lack of close collaboration between teams; when a response is required for a given issue the project can be at stand-still because of a pending roadblock that needs to be address before proceeding to the next development process.
Outsourcing can provide a major gain to an organization but often times it comes at a cost. The most ideal situation is to make sure the positives outweighs the negatives when outsourcing is being incorporated in an organization.
As a software engineer with ten plus years of experience I have witness different varieties of software development processes being utilized to release a product to the consumer. The earliest of these processes was the waterfall methodology method which promotes a sequential design process to a product from conception to product release. This method was extremely rigid and inefficient. In today’s modern software development the majority of organizations employ an agile methodology and in particular the Scrum development process which allows for an organic development and for quick development schedule.
In my organization we utilize the Scrum methodology with great results and it has allowed for our software products to have very predictable schedules and development cycles regardless of the complexity and scope of the project. I will be discussing a few of the reasons of how Scrum has benefitted my software development team.
The Scrum process allows team members the platform to which each individual can properly communicate with each other and this channel gives each team member more authority and ownership over the product they are working on. Scrum development requires each team member to work closely together on a daily basis via standup meetings. The quick daily meetings allow the team to display pure transparency over the project and inform every team member of the business priorities, work completed, future work and roadblocks on the project. Another advantage is under the Scrum process the team can produce a better quality product through shared vision and goals. Scrum process allows for continuous feedback over new features and implementation; this constant visibility to the team increases the chance to identify and expose risk and improve the chance for a successful product reception. A third benefit to Scrum development is it allows for more relevant metrics and measures to any projects. In a Scrum environment the team members who act as immediate stakeholders to the project are the persons responsible for giving proper estimates and provide optimal scheduling; timelines and budgets are based on each team member’s capability and performance.
There are many more reasons why Scrum methodology is the preferred choice for agile development and is quickly becoming the standard approach to software development.
Creating accurate project estimates is akin to a Hail Mary pass in the National Football League; there’s a very slim chance it will ever occur. The problem with providing a bold and direct project schedule and estimate at the beginning of any project is the unwavering assumption of optimism and the predetermine knowledge of lessons learned being applied. This is how many organizations operate and understandably so since it stems from our innate way of breaking down processes into several steps till we accomplish our task and reach a goal but most of us only see the best possible circumstance. These can be alleviated by following a few simple strategies and habits below; also, the action items below are not ordered in any manner and should each be treated in its own merit.
Scope to time is an idea that was born out of the Project Management Triangle also called, ‘Triple Constraint’ is the concept of given a fixed number of features and deliverables; the group will assign a time value to each and this data crunching is performed for all features to determine the total amount of estimated project development. This approach is a simple form of project estimation.
Another tactic is to communicate team assumptions to the entire team which promotes team transparency and it exhibits a healthy practice of bringing project requirements in a clearer light. This will also allow the team to avoid costly surprises during or at end of project development.
Another critical aspect of determining project estimation is identifying the risks associated with projects. Being aware of the risk involved and generating a solid plan on how to overcome is not adequate enough to withstand the intricacies project development. An important part of risk management is to be able to create a source or outlet that will mitigate and/or prevent those risks from ever occurring; teams must be proactive and not reactive.