Project Management in Practice

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

Tag Archives: technology

Competing with cheap opposition


Competing with cheap oppositionThe saying if you pay peanuts, you get monkeys used to be quite a true one. In traditional business models where all suppliers came from the same market that extended to projects as well. Today services are not necessarily procured from the market they are delivered. Competition is much wide ranging to different countries and even continents. Exchange rates can artificially put companies in an advantageous position. A reasonable salary in India or China will be significantly less than in the United States, Europe, Australia or New Zealand. This pits companies providing services in their own markets into a challenging situation. How can they compete?

Some companies have taken the route of your “local” as the reason to do business with them. Unfortunately, the world is a more savvy place today than some years ago … mostly. This tactic does not work as well today as once it did. The scenario is not limited to services being offered from cheap offshore companies. The response of many companies in these jurisdictions that seek to be competitive is to eliminate overheads by cutting training, limiting remuneration and benefits, removing office locations etc. to provide services on the cheap. Challenges are even higher competing against such organisations.

If you wish to maintain a semblance of quality, retain capable staff and intellectual property and seek to provide job satisfaction then there is a cost to that. The organisation cannot absorb all the cost. They are in it to make a profit at the end of the day. This cost has to be passed on to the client to make it work. Is this a futile exercise? It may seem the only way to compete is to trim expenditure at the cost of everything else.

I was having a conversation with a former colleague, who was of the opinion that he would seek quality every time. While an excellent idea in principle, it rarely works in practice when money is involved. We as human beings are programmed to look out for the best “deal” out there. You only have to look at the roaring trade retailers do around festive season. It is the appearance of value for money that attracts many. Think yourself … if you can stay at a 5 star hotel for 2 nights and for the same cost stay 7 nights at a 3 star hotel, which one would you choose? Maybe you choose a 4 star accommodation for 4 nights instead as a compromise? Companies are constantly balancing quality against cost.

A look at the car industry can help us take a guide in the IT world. Tata manufactures the cheapest car – Nano in India. It is not even marketed outside of India because cheap itself will not sell. There are quality criteria for entry into other markets. US manufacturers have for years relied on being the home brand to trade. As the petrol prices rise consumers have become more aware of better value for money with Japanese cars. At the same time many German manufacturers remain as premium brands that trade less on quantity and more on quality.

What IT companies need to do is to focus on showing value to the customer rather than trying to be cheap. There will be a set of customers that will equate cheap with value. In some cases companies will need to evaluate whether those customers are worth servicing. Some customers will go for cheaper option from an incumbent supplier, rather than an innovative and higher quality option, not because it is cheaper but because they are averse to change. These are customers that you need to keep in touch with if you believe you can offer a higher quality. They may one day develop the courage to change. Focus more on the end of the market that will recognise quality.

How do you communicate this quality? Change emphasis. You are local. What value is in it for the customer? You can respond quicker, have coverage for the full business hours, speak the same language, aware of business processes and local legislations. Trumpet your retention rates and certifications or technical skills of your staff. Build a relationship with your clients outside business – social or sport. You actually have selling points that cheaper ones do not or cannot have.

Image Credit: http://www.webdesignerdepot.com

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

%d bloggers like this: