4 Dimensions of Project Management

4DimensionThere are 4D’s of any software project management. Any successful or efficient Project Managers uses these 4D’s as a trade-offs or leveraging techniques when dealing with the management. The 4D’s of project management namely – Duration, Cost, Scope and Risk are used by Project Managers to handle any change requests while maintaining the feasibility of the projects.

Scenario 1 – Project Managers with only 1 dimension: Duration

The PM presents the plan and schedule to the management and is inevitably asked the question which is always asked:” How can we make this faster?”

PM response: The PM slumps in his chair and starts stuttering, “We can’t change anything, this is the only way of doing it and changing anything at this stage will lead to disaster.”

Management response: They go ahead anyway and slash the duration to what they want and ask the PM to do it anyway. Please note, management relishes the opportunity to take strategic decisions based on data and they don’t respond too well to vague terms like disaster or no change.

Here the project manager was caught in a typical 1-Dimension situation wherein the only option or alternative that he was able to give to the management was Duration. He was either unprepared or unwilling to give any alternatives or trade-offs options to the management and that led to a disastrous scenario. So now the PM is stuck with a shorter duration with no increase in the budget and no reduction in scope of the project.

A different outcome could have been accomplished if the PM would have come up with multiple Duration and Costs options. If faced with the inevitable question of “How can we do it faster?” the better response to the management is sure we can do it faster and we can do it cheaper too. I have these options which you can take a look at and then make an informed decision. I have this option 1 which will complete the project in 6 months at a cost of half a million dollars. I have another option in which we can complete the project in 4 months only but in that scenario I will have to hire a Graphics designer and an extra developer which will add a cost of 60 thousand dollar to the project.

What is the immediate effect of the presentation of these multiple options to the management? The management starts giving respect to the PM and he is being perceived as somebody who is intelligent and knows what he is doing. In short, they become aware of the fact that they are dealing with somebody who cannot be bulldozed with statements like “This is when i want the things to complete and please make sure that it is done.” Secondly Management is happy that they are being asked to make a strategic decision based on some data instead of vague threats like disaster.

There is a high possibility that even after being presented with the multiple options and various dimensions the management still goes ahead and start playing 1-Dimension card. This is when the PM has to be intelligent and ready enough to take out the 3rd dimension that is the Scope card.

“Sure if you still want the duration of the project to be shorter at no additional cost then i will have to reduce the scope of the project to achieve them and here are the options for them.”

There is very high probability that even after playing all the 3 dimensions of the project management, the PM might not get everything that he desired but we will surely be able to negotiate something and at least come out of the meeting with a feasible project. Last but not the least the PM would have gained the respect and credibility of the management which would go a long way in maintaining the sanity of the project as the project goes along. The trade-offs (Duration, Cost, Scope and Risk) are very effective tools that needs to be presented to the decision-makers so that they can take realistic decisions. To be able to present these trade-offs , the PM should be able to quantify each of these trade-offs and present as many as options to the executives.

One – Dimension Projects : Most of the internal applications that are developed in an organization are one dimensional. The only tangible option that the executives have are the duration. There is no explicit project budget and there is no assessment of risks that are done. Not surprisingly, most of the discussions and decisions are around the duration of the project as that is the only measurable entity that is before the management. Scope creep, bloated budget and slipped deadlines are common in one-dimension projects.

Two – Dimension projects :  Some organizations do add a second dimension to their plans – Duration and Cost. The benefits of adding this dimension is tremendous as now the management understands that adding a new feature or changing a feature is not “free” anymore. There is a cost involved. Even if the Cost of the project might not be paid by the end client, the management now becomes aware of the Scope creep and the cost involved with it. This knowledge is a major step forward and helps tremendously in controlling the scope creep.

Three – Dimension projects : Things get much better if the PM adds the third dimension and is able to quantify the scope of the project. By decomposing and quantifying the scope of the project, the management now has a measurable view of each of the feature sets and their impact on the business results. This trade-off becomes more powerful when it is complemented with the two dimensions mentioned above – Duration and Cost. Consider these two options and one will realize the effect of presenting this dimension with the other two dimensions.

Option 1: “Develop this particular feature capable of serving 90000 users at a cost of 100000 dollars in 6 months.”

Option 2: “Develop this particular feature capable of service 50000 users at a cost of 60000 dollars in 4 months.”

Now the management directly sees the desired business result that they are going to get and at what cost and duration.

Four – Dimension Projects: The fourth dimensions adds the assessment of risks to the projects. When this dimension is added to the project management, this gives the ability to the management to see at what level of certainty they want to achieve in the project and at what cost and duration. When the management listens to “We can deliver the agreed scope of the application with 60 % confidence at a cost of 1 million in 6 months”, they are more confident of taking the decision and are vary of creeping of the scope as they are now aware that any change request will affect all the duration, cost and Risk.

 

Ignoring Risk Management : A disaster !

Risk Management
Risk Management

Some staggering facts on software failures

According to the Standish report:  In the United States, we spend more than $250 billion each year on IT application development of approximately 175,000 projects. The average cost of a development project for a large company is $2,322,000; for a medium company, it is $1,331,000; and for a small company, it is $434,000. The Standish Group research shows a staggering 31.1% of these projects will be cancelled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates.

According to a study report done by McKinsey & Company in conjunction with the University of Oxford: 17 percent of large IT projects go so badly that they can threaten the very existence of the company. On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted

According to a study by KPMG (New Zealand): Survey shows an incredible 70% of organizations have suffered at least one project failure in the prior 12 months. 50% of respondents also indicated that their project failed to consistently achieve what they set out to achieve!

 Ignoring Risk Management: A Recipe for disaster

Software Project failures are the result of the multiplicity of risks inherent in software project environment. Software development projects are collections of larger programs with many interactions and dependencies. It involves a creation of something that has never been done before although the development processes are similar among other projects. As a result, software development projects have a dismal track-record of cost and schedule overruns and quality and usability problems. Time-to-market is the most critical factor for consumer in developing commercial software products. However the project success is difficult to predict because project scope is changed by continuous market requirements and resources are constantly being reallocated to accommodate latest market conditions. Projects for specific customers also have a large degree of uncertainty for requirements due to the customized technical attributes. Many software projects and programs involve multiple entities such as companies, divisions, etc., that may have certain interests. There is often a feeling of disconnection between software developers and their management, each believing that the others are out of touch with reality resulting in misunderstanding and lack of trust. Research shows that 45% of all the causes of delayed software deliverables are related to organizational issues. By looking at the facts and reasons mentioned above, it would be quite obvious that the Risk Management process would be quite an integral part of the Software Development process. Wrong!

According to Kwak and Ibbs (2000) identified risk management as the least practiced discipline among different project management knowledge areas. Boehm and DeMarco (1997) mentioned that “our culture has evolved such that owning up to risks is often confused with defeatism”. In many organizations, the tendency to ‘shoot the messenger’ often discourages people from bringing imminent problems to the attention of management. This attitude is the result of a misunderstanding of risk management. Most software developers and project managers perceive risk management processes and activities as extra work and expense. Risk management processes are the first thing to be removed from the project activities when the project schedule slips.

Agile and Scrum : A detailed perspective

AGILE MANIFESTO |

  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

 AGILE PRINCIPLES |

  • Satisfy the Customer – Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Embrace Change – Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  • Frequent Delivery – Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Cross-Functional Collaboration – Business people and developers must work together daily throughout the project.
  • Support and Trust – Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • Face-to-Face Conversation – The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working Software – Working software is the primary measure of progress.
  • Sustainable Pace – Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Technical Excellence – Continuous attention to technical excellence and good design enhances agility.
  • Keep it Simple – Simplicity–the art of maximizing the amount of work not done–is essential.
  • Self-Organization – The best architectures, requirements, and designs emerge from self-organizing teams.
  • Inspect and Adapt – At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

SCRUM

Scrum is a framework, a specific implementation of the agile methodology.  It is an iterative and incremental agile software development framework for managing software projects and product or application development. As mentioned in the Agile Process, Scrum relies on a self-organizing, cross-functional team. The scrum team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole. The Scrum team is cross-functional; everyone is necessary to take a feature from idea to implementation.

ROLES | that are part of the Scrum framework

There are three core roles and some ancillary roles in the Scrum framework. There is a joke about a chicken and a pig. They are talking and the chicken says, “Let’s start a restaurant.” The pig replies, “Good idea, but what should we call it?” “How about ‘Ham and Eggs,'” says the chicken. “No thanks,” says the pig, “I’d be committed, you’d only be involved.

The roles that are committed are the core roles and the roles that are only involved in the project are the ancillary roles.

CORE ROLES  | The core roles are those committed to the project in the Scrum process—they are the ones producing the product (objective of the project). They represent the scrum team.

  • Product Owner – The Product Owner represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business. The Product Owner writes (or has the team write) customer-centric items (typically user stories), prioritizes them, and adds them to the product backlog.
  • Development Team – The Development Team is responsible for delivering potentially shippable product increments at the end of each Sprint. A Development Team is made up of 3–9 people with cross-functional skills who do the actual work (analyze, design, develop, test, technical communication, document, etc.). The Development Team in Scrum is self-organizing, even though they may interface with project management organizations (PMOs).
  • Scrum Master – Scrum is facilitated by a Scrum Master, who is accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables. The Scrum Master is not the team leader, but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended.

ANCILLARY ROLES | The ancillary roles in Scrum teams are those with no formal role and infrequent involvement in the Scrum process—but nonetheless, they must be taken into account.

  • Stakeholders – The stakeholders are the customers, vendors. They are people who enable the project and for whom the project produces the agreed-upon benefit[s] that justify its production. They are only directly involved in the process during the sprint reviews.
  • Managers –  People who control the work environment.

ARTIFACTS | produced during scrum framework implementations

  • Product – The primary and the most important artifact of Scrum project is, of course, the product itself. The Scrum model expects the team to bring the product or system to a potentially shippable state at the end of each Scrum sprint.
  • Product backlog – It is a prioritized features list, containing short descriptions of all functionality desired in the product. When using Scrum, it is not necessary to start a project with a lengthy, upfront effort to document all requirements. Typically, a Scrum team and its product owner begin by writing down everything they can think of for agile backlog prioritization. This agile product backlog is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers. Typically a product backlog consists of the following items – Features, Bugs, Technical work, Knowledge acquisition. The most predominant way for a Scrum team to express features on the agile product backlog is in the form of user stories, which are short, simple descriptions of the desired functionality told from perspective of the user.
  • Sprint backlog – The sprint backlog is the list of tasks identified by the Scrum team during sprint planning. During sprint planning, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story. Most teams also estimate how many hours each task will take someone on the team to complete. It is critical that the team selects the items and size of the sprint backlog. Because they are the ones committing to completing the tasks they must be the ones to choose what they are committing to. The sprint backlog is very commonly maintained as a spreadsheet but it is also possible to use your defect tracking system or any of a number of software products designed specifically for Scrum or agile.
  • Sprint burn down chart – The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. There are also other types of burn down, for example the release burn down chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations) and the alternative release burn down chart, which basically does the same, but clearly shows scope changes to Release Content, by resetting the baseline.

OTHER KEYWORDS | in the Sprint framework

  • Daily Scrum – On each day of a sprint, the team holds daily meetings (“the daily scrum”). Meetings are typically held in the same location and at the same time each day. Ideally, the daily scrum meeting is held in the morning, as it helps set the context for the coming day’s work. These Scrum daily standup meetings are strictly time-boxed to 15 minutes. This keeps the discussion brisk but relevant.During the daily Scrum, each team member answers the following three questions:What did you do yesterday?What will you do today? Are there any impediments in your way?The daily Scrum meeting is not a status update meeting in which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make commitments to each other.
  • Sprint – A time period (typically 1–4 weeks) in which development occurs on a set of backlog items that the team has committed to. Also commonly referred to as a Time-box or iteration.
  • User Story – A feature described in the product backlog is commonly explained using a story and has a specific suggested structure. The structure of a story is: “As a <user type> I want to <do some action> so that <desired result>” This is done so that the development team can identify the user, action and required result in a request and is a simple way of writing requests that anyone can understand.
  • Epic – An epic is a group of related stories, mainly used in product roadmaps and the backlog for features that have not yet been analyzed enough to break down into component stories.
  • Spike – A period used to research a concept and/or create a simple prototype. Spikes can either be planned to take place in between sprints or it might be accepted as one of many sprint delivery objectives.
  • Tasks – Typically at the beginning of a sprint, the user stories are broken down into tasks and are assigned hours to them.
  • Tracer Bullet – The tracer bullet is a spike with the current architecture, current technology set, and current set of best practices which results in production quality code. It might just be a very narrow implementation of the functionality but is not throw away code.
  • Sashimi – A report that something is “done”. The definition of “done” may vary from one Scrum team to another, but must be consistent within one team.
  • Planning Poker – In the Sprint Planning Meeting, the team sits down to estimate its effort for the stories in the backlog. The Product Owner needs these estimates, so that he or she is empowered to effectively prioritize items in the backlog and, as a result, forecast releases based on the team’s velocity
  • Sprint retrospective – Following one of the core principles of Agile to inspect and adapt. The Scrum team believes that there is always opportunity to improve. Although a good Scrum team will be constantly looking for improvement opportunities, the team should set aside a brief, dedicated period at the end of each sprint to deliberately reflect on how they are doing and to find ways to improve. This occurs during the sprint retrospective.

SUMMARY | of Scrum framework

  • A product owner creates a prioritized wish list called a product backlog.
  • During sprint planning, the team pulls a small chunk from the top of that wishlist, a sprint backlog, and decides how to implement those pieces.
  • The team has a certain amount of time, a sprint, to complete its work – usually two to four weeks – but meets each day to assess its progress (daily scrum).
  • Along the way, the ScrumMaster keeps the team focused on its goal.
  • At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
  • The sprint ends with a sprint review and retrospective.
  • As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.