Month: May 2016

PMBOK vs PRINCE2 vs AGILE Project Management

PMBOK vs PRINCE2 vs AGILE Project Management

What are the pros and cons?

There are a range of different methodologies which are often applied to project management, with the three most commonly considered being PMBOK, PRINCE2 and Agile. If you’re trying to weigh up what are the pros and cons of PMBOK versus PRINCE2 versus something like Agile, you may find it useful to consider them in context with the project that you’re undertaking, as well as comparing one to the other.

To help you in assessing what are the pros and cons of PMBOK vs PRINCE2 vs Agile and which of these methodologies may work best in your individual situation, here is an overview of each of these systems for general project management best practice

PMBOK – pros and cons

PMBOK is short for Project Management Body of Knowledge. Users of this system find that it has more substantial frameworks for contract management, scope management and other aspects which are arguably less robust in PRINCE2. However, many users of PMBOK find that they are not entirely happy with the way this system limits decision making solely to project managers, making it difficult for handing over aspects of the management to other parties and senior managers. With PMBOK, the project manager can seemingly become the primary decision maker, planner, problem solver, human resource manager and so on.

PRINCE2 – pros and cons

PRINCE2 stands for Projects in a Controlled Environment and this is a project management program that shares more of the functional and financial authority with senior management, not just the project manager. This program has a focus on aiding the project manager to oversee projects on behalf of an organisation’s senior management. On the pros side, PRINCE2 provides a single standard approach to the management projects, which is why many government and global organisations prefer this option. It is also favoured because of its ease of use, which makes is easy to learn, even for those with limited experience. On the downside, there are users who feel that PRINCE2 misses the importance of “soft skills” that should be a focus for a project manager.

Agile – pros and cons

Agile is a more distinct program from PMBOK and PRINCE2. The Agile methodology is more flexible, making it better able to produce deliverables without the need for substantial changes and reworking. Tasks can be broken down into smaller stages and this allows for substantial risk reduction through earlier assessment, testing and analysis. The main drawback of Agile is that if it is not fully grasped, the methodology could lead to unattainable expectations.

If you’re interested in comparing PMBOK vs PRINCE2 vs Agile and you’re wondering about the pros and cons there are several answers. Each of these has it distinct differences. If you’re project needs to be small and adaptable, then Agile may be the answer. If the project manager needs to be the sole decision maker, then PMBOK could be preferable and so on. Each project manager will form different opinions and they may even change their mind on which is best based upon changes from one project to the next.

What’s the problem with Project Managers saying “no problem!” to all requests

What’s the problem with Project Managers saying “no problem!” to all requests

Rubbing-Head...-Too-MuchWhen one discusses problems that may arise through Project Managers saying ‘no problem!’ to any requests for product changes, one is essentially delving in particular into the realms of scope management.

Project managers need to anticipate and plan to accommodate requirements growth. In software development, requirements change and grow over the course of a project. The key words are plan and control. Scope creep occurs when there is an uncontrolled growth of functionality that a project team attempts to just stick into an already at capacity project phase. An inexperienced project manager saying ‘no problem’ to any request would heighten this problem.

When functionality increases in an unplanned and uncontrolled manner, consequent prioritisation of requirements is inadequate and the expanded targets make it difficult to deliver key points of functionality on time and schedule. Projects can also run into further delays, problems with quality and misdirected energy.

The key point is this: functionality can change and expand, but it must be planned; thus it will be linked with restraints of time (iterations), cost (the budget) and prioritisation of tasks (key functions are delivered first).

Agile Vs. Waterfall: Evaluating The Pros And Cons

Agile Vs. Waterfall: Evaluating The Pros And Cons

Agile and Waterfall are two distinct methods of software development. The Waterfall model can essentially be described as a linear model of software design. Like its name suggests, waterfall employs a sequential design process. Development flows sequentially from start point to end point, with several different stages: Conception, Initiation, Analysis, Design, Construction, Testing, Implementation, and Maintenance.

In contrast, the Agile method proposes an incremental and iterative approach to software design. It was essentially developed in response to the limitations of Waterfall, as a way to give designers more freedom. The design process is broken into individual models that designers work on. There is no pre-determined course of action or plan with the Agile method. Rather, designers are free to respond to changes in requirements as they arise and make changes as the project progresses. Agile is a pretty new player to the development game. However, it has made substantial gains in use and popularity in the last couple of years.

First of all, before you embark on a software design project, make sure you have the basics of software design down.  Before making a choice, it is important to do some research and understand the advantages and limitations of each approach.  Let’s take an in-depth look at the pros and cons of both the Agile and Waterfall methods of software development.

AGILE : The Pros

Agile offers an incredibly flexible design model, promoting adaptive planning and evolutionary development. Agile might be described as freeform software design. Software developers work on small modules at a time. Customer feedback occurs simultaneously with development, as does software testing.  This has a number of advantages, especially in project environments where development needs to be able to respond to changes in requirements rapidly and effectively.

Agile can be especially beneficial in situations where the end-goals of projects are not clearly defined. For example, if you are working with a client whose needs and goals are a bit hazy, it is probably worthwhile to employ the Agile method. The client’s requirements will likely gradually clarify as the project progresses, and development can easily be adapted to meet these new, evolving requirements. Agile is also an excellent option for experimental software design.

Lastly, this method also facilitates interaction and communication – collaboration is more important here than design. Because interaction among different designers and stakeholders is key, it is especially conducive to teamwork oriented environments. Different developers work on different modules throughout the development process and then work to integrate all of these modules together into a cohesive piece of software at the end of the project.


The emphasis of Waterfall is the project plan and therefore before beginning any kind of development there needs to be a clear plan and a clear vision in order. Because the Waterfall method requires upfront, extensive planning, you can launch software fairly quickly. You can also estimate timetables and budgets more accurately, which definitely tends to please clients.

Furthermore, Waterfall development processes tend to be more secure because they are so plan oriented. For example, if a designer drops out of the project it isn’t a huge problem, as the Waterfall method requires extensive planning and documentation. A new designer can easily take the old designer’s place, following the development plan without a problem.

AGILE : The Cons

Though highly flexible, Agile simply doesn’t have the structure that the Waterfall method has and this does present some drawbacks. Agile projects tend to be hard to predict, from timelines to budgets. Without a concrete plan, everything remains a bit vague and nebulous.

In addition, as previously discussed, active user involvement and intense collaboration are required throughout the Agile process. This can prove highly problematic for a number of reasons. First of all, this method of development can be quite time consuming, much more time consuming than the Waterfall method. And, it means that designers need to be committed for the duration of the project. If a designer leaves in the midst of a Waterfall method development project, it likely won’t be too big of a deal as the project is plan based. In the case of the Agile method, however, development is much more person based. Having a person drop out of the project could prove catastrophic.


The Waterfall method is incredibly rigid and inflexible. Altering the project design at any stage in the project can be a total nightmare and once a stage has been completed, it is nearly impossible to make changes to it. So, if you’re planning to use Waterfall, you will need to gather all of the requirements upfront. In addition, the problem with the Waterfall method is that feedback and testing are deferred until very late into the project. So if there is a problem, it is very difficult to respond to it, requiring a substantial amount of time, effort, and sometimes money.

So, What’s Better?

When it comes down to it, neither the Agile method nor the Waterfall method is inherently better than the other. That being said, each method does have its uses. Waterfall tends to be best for static projects, where it’s not likely that many changes will be made throughout the development process. In contrast, Agile tends to be a better option for smaller projects where changes are likely to be made during the design process. Though, keep in mind that these are just rough guidelines and suggestions. Really, when it comes to choosing a method there is not a right or wrong choice. You just need to understand which method is better suited to your project and your needs







Artificial Intelligence

Artificial Intelligence

Artificial intelligence

AI ( Artificial intelligence)  had been an extraordinary field for the past few years. From amazing development to extensive opportunities of implementation AI is slowly providing an easier lifestyle. From robots to help out at home to professional industry uses we are needing less manual power as the days go by. Automation wouldn’t be nearly as good if the machines couldn’t adapt to the changes and reflect on every situation differently.

Recently I came across an article stating that an AI lawyer had just been hired by a law firm.  This just shows the amazingly limitless potential that AI presents. If implemented in the health, security or customer service industry the profits would skyrocket. Not only do we eliminate human error but also increase work time by essentially eliminating any down time. Tests to implement more AI are already underway E.g self driving cars.  By having self driving you are eliminating taxi drivers as we would only need to call the taxi using an app on put phone and then the car would drive itself! . By eliminating humans we are increasing road safety. Sure you can argue that machines can malfunction but they are still going be more effective than humans.

Back to Ross the new layer. ” Ross, the world’s first artificially intelligent attorney, has its first official law firm. Baker & Hostetler announced that they will be employing Ross for its bankruptcy practice, currently comprised of almost 50 lawyers “.  

“ Law firm Baker & Hostetler has announced that they are employing IBM’s AI Ross to handle their bankruptcy practice, which at the moment consists of nearly 50 lawyers. According to CEO and co-founder Andrew Arruda, other firms have also signed licenses with Ross, and they will also be making announcements shortly.

Ross, “the world’s first artificially intelligent attorney” built on IBM’s cognitive computer Watson, was designed to read and understand language, postulate hypotheses when asked questions, research, and then generate responses (along with references and citations) to back up its conclusions. Ross also learns from experience, gaining speed and knowledge the more you interact with it.

“You ask your questions in plain English, as you would a colleague, and Ross then reads through the entire body of law and returns a cited answer and topical readings from legislation, case law and secondary sources to get you up-to-speed quickly,” the website says. “In addition, ROSS monitors the law around the clock to notify you of new court decisions that can affect your case.”

Ross also minimizes the time it takes by narrowing down results from a thousand to only the most highly relevant answers, and presents the answers in a more casual, understandable language. It also keeps up-to-date with developments in the legal system, specifically those that may affect your cases.

This is only the start who know one day AI will be able to formulate better Ai and so forth causing an evolution in all industries ( hopefully) .  The goal in my eyes should be to eliminate any forms of errors. History shows us human aren’t capable of doing so maybe the machines are. “  


  • Image link :
Estimating the total cost of Agile projects

Estimating the total cost of Agile projects

Estimating the total cost of Agile projects

Questions about how to estimate the total cost of Agile projects are questions about how to do fixed-price, fixed-scope contracts. Fixed-price, fixed-scope contracts are adversarial and often mutually disadvantageous, so I wouldn’t encourage them.

How would a team estimate the cost of fixed-scope work upfront? Here are several approaches for you to consider:

Estimate the project the same way you currently do. If the approach that you’re using provides enough accuracy and you’re able to make a profit, then why change? Any other approach is as likely to be as inaccurate as what you have now.

Estimate the project using a coarse scale … such as T-shirt sizing, and then assign a dollar range to each size. For example, have the team work with the product owner to create a list of User Stories at a high level (epics). The team then estimates the epics on a very coarse abstract scale such as T-Shirt sizes ranging from XS through to XL [XS, S, M, L, XL]. Because we’re only concerned with order-of-magnitude and not about accuracy, this should be a relatively quick operation.

We would then assign a dollar range to each size on our scale; XS would be $10,000-$20,000, S would be $40,00-$80, 000, M would be $150,000-$200,000, etc. We would tally up the final figure to give an upper and lower bound for the total cost.

If the customer wanted a fixed price project then we would quote the upper bound figure to compensate us for the additional risk that this might incur. If they’re willing to work on a more flexible basis (say fixed-cost, variable-scope), then we could consider a quoting a lower cost.

Change the conversation. Changing the conversation is my preferred solution, because changing the conversation helps to educate the client that Scrum is more than a different way to do the same old thing … rather it’s systemic change.


This approach is also the most difficult.

To use it effectively requires a mature understanding of the different arguments for and against. It is also a realistic answer to the question of how to determine the cost of software upfront. We don’t know [although we can provide educated guesses.

A more meaningful question is how much does the client value the new software? If the client is unable to answer that question, then perhaps the new software has no value at all and is not worth creating. If the client has an understanding of the value of the software (perhaps through a cost/benefit or ROI analysis) then the breakeven point should serve as then upper bounds of the teams budget.

Taking this approach is not without its risks. There is certainly the possibility that the client will decline our services. Mature agile consultancies understand this and are often willing to walk away from work that results in a mutually disadvantageous arrangement.

Source and additional source:

Costing Agile projects: How to cost Agile projects

Software estimates: the total cost of Agile projects

SCRUM | There are three artifacts

SCRUM | There are three artifacts

There are three artifacts in Scrum,

The Product Backlog, the Sprint Backlog and the Burndown  Chart

The Product Backlog is a list for all the requirements. These are high level user stories that features descriptions, all of which have business value priorities. The product backlog is constantly changing. The Product Owner  owns this backlog, he or she will gather feedback, suggestions and additional requirements from stakeholder to add to the backlog. In other types of project management methodologies, there are heavy requirement documents, technical specs, etc. Fortunately with Scrum, the Product Backlog replaces these and the agility is well used with the ability to easily adjust the content of this.

A typical Scrum backlog comprises the following different types of items:

  1. Features
  2. Bugs
  3. Technical work
  4. Knowledge acquisition


Conceptually, the team starts at the top of the prioritized Scrum backlog and draws a line after the lowest of the high-priority items they feel they can complete. In practice, it’s not unusual to see a team select, for example, the top five items and then two items from lower on the list that are associated with the initial five.

The Sprint Backlog is a subset of the Product Backlog. This is the repository of the highest priorities deemed by the Product Owner. These requirements are broken out into tasks, estimated, and clearly defined by the Scrum Team. Once we start a Sprint, the Sprint backlog does not change.

The sprint backlog is 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.

An example of a sprint backlog in a spreadsheet looks like this:



The Burndown Chart is a chart that indicates how much work is remaining in the Sprint. This chart is hung up in an area that everyone can easily see, including the Scrum Team, the Product Owner and Management. This is updated on a daily basis by the ScrumMaster, after hearing from the team what they have accomplished in the Daily Scrum Meeting.


Let’s take an example using the sprint burndown chart above. As you can see, the team in this scenario pulled in too much work initially into the sprint backlog, and still had nearly 250 hours to go on day 8 of a 21-day sprint. The product owner was consulted and agreed to remove some user stories from the sprint. This resulted in the drop on the chart between days 7 and 8. We can also see that on day 8 they had completed nearly 35 tasks. From there, the team made consistent progress and finished the Scrum sprint successfully.