Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Tag Archives: software

5 Questions every Project Manager must ask


5 Questions Project Manager must askProjects are inherently risky endeavours and require plenty of shepherding to ensure successful completion and the desired results. Key to successful project management is clarity of understanding on what you are trying to deliver. It is easier said than done. Different people can read the same requirements and have different impressions of deliverables. I’ve been thinking about some of the strategies I have used and seen successfully applied. Following is a set that I have found very useful. I find asking some, if not all of these questions consistently gives me best chance of success.

Q1: Can I focus on outcomes rather than outputs?

Most projects in my experience are too preoccupied with delivering the outputs. Predominant procurement methods are partly to blame for the culture of judging project success by its outputs. For example, an output may be a new software but the desired outcome is faster processing of orders. No one has monopoly on good ideas. In many instances requirements are gathered prior to projects starting, where assumptions fail on first inspection. Ask yourself if you have the ability to go back to the stakeholders if you were faced with such a scenario. If it is output that you must produce regardless of outcome, then your chances of success are low. On the other hand, if you know what the desired outcome is, you can articulate why a particular option may have more merit than another.

Q2: Do I have enough sponsor involvement?

I see plenty of projects languishing with project managers struggling to get buy in from various stakeholders. Any organisation is a political one by nature. There are stakeholders with various views. Some may have been keen to undertake the project; others may not have been so enthusiastic. Organisations have to prioritise their portfolio and you may require contribution from those that had their projects or ideas passed over. If you try to manage your way out of that, there is little hope of success. This is where involvement of your sponsor is key. They are usually in a position of authority to ensure cooperation, provide you with strategies to work within the organisation and remove obstacles before they become showstoppers.

Q3: Am I working to artificial deadlines?

I see many instances where projects are running to particular deadlines not because of level of effort required, but because someone in management has undertaken to have the outputs delivered at a certain date. Fred Brooks Jr, father of IBM/360 is one of my favourite authors. In his book “The Mythical Man Month” he gives a great example – It takes nine months childbirth. You can put nine women, you’ll get nine children, but it’ll take you nine months (paraphrasing). The effort is what it is. If artificial deadlines are to be met, it must come by trading off scope in the project. Simply throwing more staff at it does not solve the problem. In some cases you may be able to reduce elapsed time by throwing more resources. But beware, what takes one person 100 hours, will not be delivered by 100 people in one hour. There is a cost of communication and coordination.

Q4: How am I going to transition the outputs to the business?

So you have a set of outputs from the project … process, software, document, building … whatever these may be. Now what? The only way the customer can achieve any benefit out of these is once you have transitioned these into the business. I see many projects leaving transition planning to the end. That is always too late. The end of the project is usually a swarm of activity, many planned, many unplanned but necessary. You need to have planned your transition up front. Organisations have various levels of change appetite. You need to consider if you can take a big bang approach or need gradual transition into service.

Q5: What does my gut say?

If you are an experienced project manager, then trust your instincts. Our brains are programmed to catch patterns. You may get a feeling that something isn’t quite right. I have seen project managers ignore that if they have not been able to verify if there is indeed a need for concern. By the time they have realised what it is it is too late. If your gut tells you something is wrong, stay at it. Until you find out what it is. Have a method that you apply to it. Go through your risk register, deliverables, product descriptions, milestones. At first if you don’t see it, stay vigilant. Ignoring it is just about the worst thing you can do.

There are bound to be plenty of other questions that you should ask yourself. What is your list?

Image Credit: All-Free-Download.Com

Proof of Concept, Prototype, Pilot, Agile … confused?


Proof of Concept, Prototype, Pilot, Agile … confusedEvery industry sector has its own jargon that users or system developers use. IT is no different and plenty of words are used interchangeably that different stakeholders take to mean different things. This often makes for difficult conversations down the track. My colleague Nathan Heazlewood recently put in some effort in defining some of these. Thought he did an excellent job, well worth sharing. Hopefully it comes in handy in avoiding mismatches of expectation.

Proof of Concept (PoC): a small exercise to test a discrete design idea or assumption. An example of a POC is testing whether one technology talks to another.

Prototype: a system that tries to simulate the full system or at least a material part of it. May be completely discarded should a production version follow.

Pilot (or trial): A Pilot uses the full production system and tests it against a subset of the general intended audience. The reason for doing a pilot is to get a better understanding of how the product will be used in the field and to refine the product.

Agile development: An ‘agile’ application is one that is built to production quality in small incremental steps, some of which may be put into ‘production’ before the complete system is complete.

Production: A production system is the full system suitable for use by the complete target user group with the level of robustness and functional and non-functional agreed within the associated contractual documents.

Proof of Concept

A Proof of Concept (POC) is a small exercise to test a discrete design idea or assumption. An example of a POC is testing whether one technology talks to another. To be deliberate, a POC should clearly state what it is to be proven and to what degree. For example, it may not be enough that a message can be transferred from system A to system B if the complete solution calls a specific level of performance and reliability. You may need to test under certain conditions. POC’s often take the outward form of a simple “Hello World” but that may not be enough if the system needs to support an extended character set.

Characteristics In Scope Out of Scope
  • In the interests of minimising time and cost a Proof of Concept will relate to only small parts of a complete system.
  • A POC will utilise a development or test environment where possible to minimise change authorisation overheads of using a production environment.
  • Non-functional considerations will generally be ignored unless specifically requested.
  • Assessment of one or more important aspects of what might be involved with a production system. Only aspects specifically stated as being ‘in scope’ will be regarded as part of the ‘Proof of Concept’.
  • Functionality
  • Performance
  • User data for retention
  • Re-usable code
  • Scalability
  • Concurrency/capacity
  • Usability
  • Backup of data or code
  • Security
  • Backwards or forwards compatibility
  • Multi-browser or multi-OS support
  • Reliability
  • Availability
  • Documentation
  • Monitoring

Prototype

A prototype is a system that tries to simulate the full system or at least a material part of it. Prototypes are used to test the viability or usefulness of a system or subsystem. The only objective of a Prototype is to get a defined group of intended users of the projected system in front of the prototype and he/she/it (the user might be another system) should be able to visualize the experience of using the complete system. A prototype may provide some re-usable components that can be re-used in a pilot or production version, however it is also possible that it will be more efficient to re-do most or all of the system.

Characteristics In Scope Out of Scope
  • In the interests of minimising time and cost a Prototype will be assembled quickly with a level of quality intended for demonstration purposes only.
  • Functional aspects may be mimicked utilising ‘short-cuts’ or ‘work-arounds’ to minimise time spent on the prototype. These should be replaced with robust measures for a production system (e.g. ‘local copies’ of data may used rather than connections to data sources, components will not be fully documented or commented, testing may be minimised etc).
  • Non-functional considerations will generally be ignored unless specifically requested.
  • A prototype should only be tested for a defined period after which it will be ‘switched off’ while a production version is established.
  • Data used in a prototype should be ‘test’ data and will be disposed of at the end of the prototype demonstration period.
  • Components of a prototype may be completely discarded prior to building a pilot or production version.
  • Functionality
  • Usability
  • Backup of code
  • User testing
  • Limited user familiarisation
  • Performance
  • User data for retention
  • Re-usable code
  • Scalability
  • Concurrency/capacity
  • Backup of data
  • Security
  • Backwards or forwards compatibility
  • Multi-browser or multi-OS support
  • Reliability
  • Availability
  • Documentation
  • Monitoring
  • Full ‘factory’ or ‘unit’ testing
  • Training

Pilot (or Trial)

A Pilot uses the full production system and tests it against a subset of the general intended audience. The reason for doing a pilot is to get a better understanding of how the product will be used in the field and to refine the product. Maybe there are some open ended questions about scalability that only a live audience using the product can answer. You may consider prepping your pilot group to evaluate the full breadth of the application and give them channels to provide feedback.

Characteristics In Scope Out of Scope
  • A system as robust as stated within contractual documentation.

 

  • Functionality
  • User data for retention
  • Re-usable code
  • Usability
  • Backup of data or code
  • Security
  • Limited documentation
  • User testing
  • Training for pilot personnel
  • Other considerations As stated within contractual documentation (e.g. Statement of Work)

 

  • As stated within contractual documentation (e.g. Statement of Work)

 

Agile

An ‘agile’ application development is one that is built to production quality in small incremental steps.

Characteristics In Scope Out of Scope
  • Incremental releases of components of a system to a level of robustness as defined within the Agile documentation
  • Quality/robustness is intended from the outset, however only for a limited part of the overall system to begin with, with additional functions added over time.
  • As stated within contractual documentation (e.g. Statement of Work)
  • As stated within contractual documentation (e.g. Statement of Work)

Production

A production system is the full system suitable for use by the complete target user group with the level of robustness and functional and non-functional agreed within the associated contractual documents.

Characteristics In Scope Out of Scope
  • A system as robust as stated within contractual documentation.
  • As stated within contractual documentation (e.g. Statement of Work)
  • As stated within contractual documentation (e.g. Statement of Work)

Credits: Nathan Heazlewood, who adapted it from http://www.contenthere.net/2007/03/poc-prototype-or-pilot-when-and-why.html

Image Credit: austinstar.hubpages.com

Is agile and PRINCE2 compatible?


My project management experience is in the field of software development. I deal daily with developers that espouse the value of agile development methodologies. Having come from a development background myself, I am skeptical about all that is said about agile. In saying that, I do see some benefits – especially the first principle of continuous and incremental delivery of software. However, a question arises … is PRINCE2 compatible with such methodologies, and vice versa.

For subsequent post on use of Agile and PRINCE2 together refer to this.

Let us quickly review the highlights of the 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.

Now let us consider the realities of bespoke software development. The project cycle starts with your organization given a set of requirements from a client and you having to provide an estimate to deliver to the requirements. As soon as you commit to a fixed price, scope and duration, there is effectively no room for agile. Depending on feedback, you cannot adjust the behaviour of the application – you will likely blow price, scope or duration – most likely all of them.

In PRINCE2, there is emphasis on the business case being continually evaluated to ensure the outcome is still desirable. PRINCE2 is also very process oriented – as evidenced by the 7 processes. It cannot therefore accept the first principle of agile development. There must be a process that states the requirements and any changes to the baselines and their impact. This can then be evaluated by the project board to evaluate whether the project is still desirable.

Working software over comprehensive documentation is a dangerous prospect in my opinion. Whenever there is squeeze on project time, documentation is usually the first casualty. This may produce working software at the time; however, it adds untold grief once it has been delivered. Anyone maintaining the system, whether it be your support team, the client’s IT team, or a third party will come to regret it. While I never enjoyed documentation as a developer, I learned to live with it as a necessity of quality work.

Responding to change is often trumpeted as a major gain of agile approach. Self organizing teams are put forward as a strong productivity source and one that can do away with a traditional project manager. These however do not take into account the inter-relationships between the projects, ability to analyze the impact of the changes to baseline, ability to hand over to an IT organization from project to Business As Usual (BAU).

One striking similarity between agile and PRINCE2 is how both treat the planning horizon. Both recognize that you can only plan so far in advance. Agile approaches do it by planning sprint content, PRINCE2 does it by planning by the stages. In that respect, there is some compatibility between the two. I see great value in utilizing some of the agile principles during the development phase of the project. Once I as a project manager assign the work package to the development team leader, if they use agile techniques to deliver within their tolerance levels, who am I to object?

PRINCE2 makes a distinction between the management products of a project and the specialized ones. Development of software here is a specialized product and therefore not specifically included in PRINCE2. Beyond the delivery stage of the project, I do not see agile meeting the requirements and expectations of executives and management to contract development services for a fixed fee.

In comparison, ITIL is probably more aligned to agile approach – especially during service operation stage. Once software is delivered into BAU, there is a continuous requirement to keep it running in an optimal mode, include additional functionality or evolve with the changing requirements of the organization. A programme of work can be created with continuous service improvement goals.

Tailoring is what makes or breaks your PRINCE2 project. Make sure you tailor it to suit your requirements. Pick from agile methodologies what you want and in which stages. Do not get locked into a specific one. When used, go more by the principles of agile manifesto, rather than a prescribed, particular method.

%d bloggers like this: