A12: AGILE

Agile is a project methodology that is lean by nature and is suited to small and medium software deployments of less than six months. They can be scaled up but this is less common. The agile development itself tends to run for two to three months and is broken down into SPRINTS that normally have a duration of two weeks each.

Agile is less structured then the very structured Waterfall methodology and could be described as quite loose. There are many different variations of Agile and these will be described in more detail further on in my series. These variations include Scrum, SAFe (Scaled Agile Framework), Dynamic System Development Method (DSDM), Extreme Programming (XP) and Lean development.

For project managers Agile involves less structured management and ownership of tasks. The requirements (Features/ Product backlog) rests with the product owner. The features should be delivered and tracked using burn down charts. The project manager should monitor progress and update the project team accordingly. As Agile project duration is quite short, daily stand ups (or Scrums) are normally held each morning during the project. These should last no more than fifteen minutes and should simply outline what tasks are to be completed today, what tasks were completed yesterday and what issue/bottlenecks have arisen that will delay progress and delivery. As mentioned, the build and deployment of any product software will be managed in sprints which typically can last between two and six weeks.

The benefits associated with Agile are:

▪ Quick results and delivery

▪ Accommodates changing requirements

▪ Increased customer involvement and satisfaction

▪ Less structure

▪ Focus on product quality

▪ Development team empowerment

▪ Enhanced team motivation

▪ Cost control

▪ Focused delivery

▪ Flexibility and adaptability of delivery

▪ Risk is less on the basis of smaller timescales, less tasks to complete.

• Enhanced collaboration with teams internally & customers

▪ Focus on continuous improvement

▪ Scope creep can be managed more effectively

▪ Increased focus on time and cost and metrics associated with these elements

The problems associated with Agile are

▪ Project managers have less control

▪ Less task oriented

▪ Loose methodology

▪ Lack of project documentation

▪ Product developers can be overworked

▪ Communications can be difficult between team members

▪ Scaling agile to bigger deliveries is difficult

▪ Need experienced PMO team

▪ Culture needs to adapt to Agile

▪ Complexity of product deliverable can affect timelines

▪ Testing can be rushed & with more emphasis on end user testing than system testing

▪ Requirements (Features) may not be stable, causing delays

▪ Risk is higher on the basis that strict project management is not adhered to.

A13: ALLOCATION

Allocation in a project context tends to be about the number of projects a project manager is working on. Depending on the size of a business PMOs will track who owns or is managing a project via an allocation list. This list should show the customer’s name if the project is external, business unit or department if internal and the name of the project and the project manager. Other information regarding status of projects can be contained via other tracking mechanisms.

Essentially what one has been allocated is the same as what one has been assigned, they both mean the same. Project managers as they gain experience should be able to manage numerous projects concurrently and this obviously will depend on the projects running within a business and the projects allocated to project managers.

A14: AMBIGUITY

Ambiguity means being open to more than one interpretation. If something is ambiguous it is not clear what it means or stands for. This can be crucial in any project. The initial reference material in most projects is the contract and this needs to be free of ambiguity. However, from my experience working on projects this is rarely the case. Ambiguity can cause difficulties in planning and resourcing a project. If there is ambiguity in the contract, then creating a project charter can be troublesome and complex especially if it’s a customer-based deliverable and not an inhouse project.

If the contract is ambiguous, then the project charter will contain ambiguity and any plan created on the basis of this will inevitably prove difficult to fulfil. Delays and disagreements on scope could ensue. My advice for sales and legal teams who produce contract text is to engage with project managers and the wider PMOs to make sure that deliverables within contract are clear, concise and unambiguous and most importantly can be delivered as part of a project or program of projects. The contract needs to take account of the fact that project managers will most likely be assigned with implementing and delivering its contents so it needs to read well and be clear and concise in its content.

A15: ANALYSIS

As a project manager analysis of plans, risks, resources, stakeholders, customers and requirements is common place. The level of analysis can vary though depending on the task at hand and the size and complexity of the project you are delivering. What analysis entails is a detailed examination and investigation of core data, processes and structures. Project managers need to be accustomed at planning but whilst this may sound obvious the analysis that needs to occur as part of this maybe not be.

During the pre-planning and mobilisation stage of a project a project manager needs to analyse and examine the contract, scope, resources, project plans, risks, issue and dependencies and critically analyse what the project definition is and the necessary methodology to deliver the project.

As a project develops through the various stages the project manager needs to analyse requirements, design and testing documentation. Towards the end of the project a project manager needs to analyse everything that has gone before to reach the closure phase and then draft a lesson learned document that should analyse and be critical of how the project was delivered and whether it was a success or not. Other analysis will take place during the project but these are the main areas that critical analysis will be needed.

A16: APPLICATION

The term application is quite common in any technical software project delivery. An application, applications or Apps as they are commonly referred to are software program/s that can run on your computer (desktop), laptop, tablet or mobile device. Web browsers such as Safari, Google Chrome, Firefox, e-mail programs, word processors, games, and utilities are all example of applications. Each program should have a specific application for the user.

A17: APPLICATION PROGRAMMING INTERFACE (API)

An application programming interface (API) is essentially a communication tool between two different applications so that data can be transferred quickly, easily, securely & efficiently. It contains defined rules that enable and facilitate the communication.

The API allows companies transfer data to other companies, between internal business units and other third parties, as it acts as a middle / intermediary layer that can process data transfers.

The main power an API gives a business is the capability to connect internal applications used in their day-to-day operations and business as usual work. This can reduce costs, increase efficiency and speed of work and streamline effort and time used. Another benefit is the integration of applications within an organisation.

A18: ARCHITECTURE

Computer architecture is defined as how a computer system is designed, rules and methods that describes its implementation, how hardware and software interact within that design and also what technologies it is compatible with. The four layers of computer architecture are the hardware, operating system, software, and user layers

A19: AS-IS (CURRENT STATE)

As-is (Current state) is a part of the business analysis function which is a derivative of the project management function. Some but not all PMO (Project Management Offices) use business analysis to execute the business requirements part of the project. Essentially what a business analyst does is ascertain the requirements of the customer to design and build a particular system, product, or service.

For example, at a simple level if you wanted to a buy a car but wanted someone to do it on your behalf, then you are not just going to ask this person to buy any car. Some analysis is needed to ascertain the low-level requirements. What type of car do you want, 3, 5, 7-seater? Do you want a new or previously owned car? What brand? What model? What colour? What engine size? What fuel? What price range? and so on until all requirements are gathered. 

In the example here the to-be or future state would be the new or previously owned car you end up with as per the agreed requirements. The as-is position (current state) is the position you are currently in. Do you have a car now? Maybe you own a motor or push bike. Whatever your current situation is, this is deemed as the as-is or current state.

Depending on the business unit that requirements are being drafted for or whether they are system or process requirements, process flowcharts with swim lines can sometimes be used to depict graphically and visually the as-is (current state) and the to-be (future state) position. Microsoft Visio is a widely used tool that can aid the production of flowcharts. Business analysts tend to be skilled in using this. If the requirements are more text driven, then these will be listed in a requirements matrix and coded accordingly for management and testing purposes.

A20: ASSIGNING

Assigning is similar if not the same as allocating. In a project context this invariably means the number of projects that have been assigned to or allocated to a project manager. Depending on the project managers level of experience they should be able to manage at least two projects concurrently. However context is important as I have managed projects before which were in fact programs. If you are managing a project which has more than 5 workstreams or sub projects attached to it and depending on its size and complexity of delivery it could be classified as a program. Please see “Allocation” above for further information that crossovers with “Assigning”