quantmleap

Software development projects are unique from the perspective that their state changes substantially during a period of time called ‘Implementation’ (what others might also call ‘deployment to production’ and many other variations on this theme). The uniqueness of their status is driven from the fact that throughout a large portion of their project life-cycle they are nothing but a potential waiting to be realized. It is only once they are ‘moved’ into the organization’s production environment and added to the official technology asset register that they become a ‘real’ thing, a technology asset that can be used to realize the business purpose for which it was created.

Part of the uniqueness  of software projects compared with, for instance, construction projects, arises from the fact that while (most often) a building is being progressively built and elaborated on in a single physical location, software is subjected to transformations that take it across a number of environments before it reaches its final resting place in the ‘production’ environment. The key to the underlying risk embedded in this process is in the fact that most often the various environments through which software needs to be migrated are not identical to the final and last stop.

To illustrate the journey that a piece of code needs to go through let’s assume that in a typical software environment the software code will need to go through the following steps:

1. Development environment
2. System Testing environment
3. System Integration Testing environment
4. Stress and Volume testing environment
5. User acceptance Testing environment
6. Pre-Production Deployment environment
7. Production environment

The obvious risk that needs to be managed throughout this process is the similarity (or most often – lack of) between these various environments. The journey that the software needs to take from the time it is being developed by the programmer until it is placed in a platform accessible by the end-user is perilous and fraught with danger to say the least.

While master project plans refer to ‘Implementation’ in a short and concise manner, they are quite often accompanied by detailed and robust installation and deployment check lists and notes. In a way, deploying software into production is a project in its own right, accompanied by formal artefacts and sign-offs.

So what key artefacts would be needed, as a minimum, to accompany a successful production deployment? Let’s looks a few and explain why they are and what they are good for:

1. Stakeholder matrix - all people and organization units (internal and external) necessary for successful deployment. This will include, for example, the project team assigned to the deployment, support groups needed, all other business and technology interested parties. A detailed RACI will be required in order to ensure clear roles and responsibilities are identified such that there is no ambiguity regarding who does what and in what capacity.
2. Implementation Plan / Detailed Installation Instructions / Run Sheets – detailed lists determining what needs to be done, when it needs to be done and who is going to do it. All relevant information for carrying out these instructions should also be included, including names of servers, application versions, and any other parameter needed. No detail (unless it is absolutely trivial) should be left for interpretation or personal opinion).
3. Go and No-Go decision points - a  good plan must have continue / stop points with clear instructions how these decisions will be made and by whom. Should a No-Go deemed to be appropriate, the plan should include a detailed Back-Out plan with all relevant instructions of how to reverse the work done so far so the organization’s production environment is left unaffected.
4.  Post Deployment Verification –  it is a good practice to complete the deployment with a number of verifications aimed at confirming it is successful from a technical and business perspectives. These verifications are generally called Technical Verification Testing (TVT) and Business Verification Testing (BVT). The first is executed to confirm the deployment is technically sound while the second is executed to confirm both the deployed application as well as any other application touched on during the deployment are still working correctly.

There is more, much more, to transitioning a software product to production. The above, though, is the minimum required to ensure the hard work put into developing and testing the software product are not lost due to lack of attention to proper migration into the business hands.

Think about it!

G’day folks

As we celebrate Australia Day here down under I thought it would be a great opportunity to acknowledge the contribution of OZ bloggers to the on-going discussions around project management.

Having followed these bloggers, via their respective blogs, for quite some time now, I can honestly say that although they are but a few, their contribution to public debate and distribution of experience and knowledge is substantial.

So here they are (in no particular order), and if you are not following their blogs already, take this opportunity to explore their vast writing and follow them in the future:

1. Craig Brown’s Better Projects
2. Kailash Awati’s Eight to Late
3. Paul Culmsee’s Clever Work Around
4. Stephen Duffield’s Invicta Projects
5. Pat Weaver and Linda burne’s Mosaic
6. James Pierce and Nigel Dalton’s Luna Tractor
7. The Team from Anecdote
8. Matthew (Matt) Hodgson’s Matt’s Musings

Wishing you all a wonderful Australia Day

Shim.

Just for the fun of it, I have used http://www.tagxedo.com/ to create a Word Cloud image, based on keywords appearing in my blog (see previous image HERE).

Here’s what I got:

Over the years I’ve seen many attempts to construct the “10 commandments of project management”. I believe there is an element of cheekiness in this as it suggests a divinely inspired set of rules, wholly encompassing (or should I say holy encompassing) a complete project management experience. Chutzpah or not, I am going to give it a go as well. But before I lay out my own proposal I’d like to provide a quick overview of those who so bravely came before me, putting their neck on the line in the search of the holy grail of project management.

So here we go:

Michelle Young Cavanaugh published the following in TechRepublic in 2000:

1. Thou shalt have a project with goals
2. Honor thy project objectives
3. Thou shalt commit to the schedule that management hath given thee
4. Remember thy checkpoints
5. Thou shalt delegate tasks to thy manservant or maidservant or staff
6. Thou shalt create a picture of thy project schedule
7. Honor thy team members
8. Thou shalt commit thyself and thy team to the project
9. Thou shalt document extensively and keep thy team informed
10. Thou shalt encourage creativity

James M. Kerr published the following in ComputerWorld in 2006:

1. Thou Shalt Narrow Project Scope
2. Thou Shalt Not Suffer a Fat Team
3. Thou Shalt Require Full-Time Business Participation
4. Thou Shalt Establish Project Review Panels
5. Thou Shalt Not Provoke Burnout
6. Thou Shalt Seek Outside Assistance as Needed
7. Thou Shalt Empower Project Teams
8. Thou Shalt Use Project Management Tools
9. Thou Shalt Reward Success
10. Thou Shalt Not Tolerate Quick-and-Dirty Work Efforts

 Robin Hornby, in “A brief guide to the art of righteous project management” suggests the following:

1.  Thou Shalt Speak Thy Truth
2.  Though Shalt Not Say ‘Yes’ in Haste
3.  Thou Shalt Lead Thy Sponsor Down the Path of Reality
4.  Thou Shalt Not Present a Single Point Estimate
5.  Thou Shalt Pay for Quality, Just as Surely as Thou Payest for Thy Errors
6.  Though Shalt Not Avoid Conflict
7.  Thou Shalt Put Thy Stake in the Sand
8.  Thou Shalt Not Plan The Unknowable
9.  Thou Shalt Rid thyself of Incompetence
10.  Thou Shalt Not Assume That Which is False

Edward Yourdon, citing the above ComputerWorld list, suggests the following in his Yourdon Report:

1. Don’t fail to identify the key “players” who will ultimately declare “success” or “failure” for your project
2. Don’t fail to clearly identify (preferably in writing!) what constitutes “success” for your project
3. Don’t confuse “estimating” project schedules and budgets with “guessing” or “negotiating”
4. Don’t ignore the non-linear nature of tradeoffs between people, time, money, and quality when negotiating key project parameters
5. Don’t attempt to “freeze” user requirements; do expect “scope creep,” but don’t accept “requirements churn”
6. Don’t allow developers and key end-users to stop communicating with each other
7. Don’t commit teamicide
8. Don’t ignore whatever software processes the project team has committed to
9. Don’t skimp on risk management
10. Don’t forget the importance of a “daily build” approach

 There are others, but I think I will stop here.

And now, without any further ado (drums in the background….), here’s my humble go at The Ten Commandments of Project Management:

1. Know your goals
2. Know your deliverables – Know what DONE looks like and Know how DONE is measured
3. Know your schedule, cost and technical performance measures
4. Know your risks and your risk plan
5. Know your stakeholders
6. Know your team members
7. Adapt your communication to the listener
8. Treat your team members with respect and with dignity
9. Expect your team members to do their job but don’t demonstrate blind faith
10. Take it easy – enjoy what you do – or else find another job

Think about it!

When I was but a young child my mother read me a story that, for all intents and purposes, came straight out of the Grimm brothers library. The story was about a project manager that was lucky enough to manage in the most perfect, supportive, positive, encouraging, politics free organization. The project manager had the unconditional and relentless support of his (although it might have been ‘her’) project sponsor and all stakeholders, internal and external, have gone out of their way to offer the support and the buy-in necessary to make sure the project is delivered exactly on time and right on budget.

As I grew up I discovered that this, like many other childhood fairy tales, was nothing but a feel-good story as in reality there are no such things as perfect conditions and consequently there are no such things as perfect projects.

I argued the case in an earlier post (see HERE) that not all project managers are born equal (so to speak) as some are lucky (or smart) enough to work in mature organizations while others (and IMHO – the majority of us) are unlucky and are bound to operate in less than mature environments.

Further to the above I believe it would be also prudent to mention that project management (be it a profession or not) carries some functional components, the complexity of which cannot be taught in training schools or PMP learning institutions.

 While project management teaches you that…

• communication is a key component of the project manager job – it does not teach you how to communicate effectively and productively
• organizations are committed to the preservation and maintenance of historical records – from my experience – very few actually do
• there are some challenges in managing projects in matrix organizations, it does not teach you how to navigate through the bureaucratic maze this arrangement actually creates
• projects are a temporary endeavours it does not indicate they can – and do – turn into a permanent headache

One of the areas, training cannot equip you with the relevant skills to successfully deal with, is bureaucracy. Organizational bureaucracy, driven by fear and incompetency, can cripple, maim, or at least – weaken, even the strongest minded, self-assured and confident individual. Having been dealing with this modern reflection of incorrect risk management attitude, I have little respect and little appreciation to the role played by the Quality Assurance Gate Keepers, who, by and large, add negative value to the business by hiding behind process instead of using common sense, while blocking projects from moving into production.

My solution: Relax Service Transition and Change Management processes and allow project managers to do their job. Use the funds you saved on financing the dedicated and over elaborate Service Transition and Change Management department and utilise it to equip the projects with project administrators who can help and maintain audit trails, and demonstrate compliance with corporate project auditing requirements.

Think about it!

What might be standing in the way of …

• What might be standing in the way of real social networking is the excessive reliance on social networking tools
• What might be standing in the way of deep and meaningful communication is the number 140
• What might be standing in the way of keeping good friends is the effort required to maintain too many friends
• What might be standing in the way of quality communication is populism and ranking
• What might be standing in the way of dialogue and conversation are the ‘retweet’ and ‘Like’ buttons

Think about it!

Common wisdom will tell you that Intuition is an internal perception of reality that is not directly associated with any reasoning process. If you are a project manager early in your career you will most likely seek guidance and mentoring from more experienced project managers. And as you observe their conduct there is a good chance that along the way, when inquiring about this decision or another, you will get a response suggesting that their decision is based on gut-feel, i.e. their intuition.

There is a powerful body of evidence suggesting that some people are ‘gifted’ with consistently accurate intuition that allows them to make successful decisions and predictions about the possible outcome, the result of their action. We all know some “how-to” books, written by professionals, primarily in areas of finance and investments, advising on the steps they have taken in genuinely uncertain times, resulting in out of the ordinary success.

By its very nature, invoking intuition is a product of dealing with situations of uncertainty, or more specifically in the way we react to a possible risk (and opportunity). It is our immediate response to a question that results in an action (or deliberately refraining from one).

In a project environment, intuition can and does play a role in planning activities. Subject Matter Experts (SMEs) are the ones we mostly rely on to provide planning estimates. We rely on SMEs in varying circumstances; we need their advice to forecast project activities for which they have direct past experience; we also ask for their advice to forecast project activities for which they do not have direct experience but are believed to be close enough to a point where their gut-feel and intuition could provide a good-enough estimate.

Makes sense, doesn’t it?

Well, actually, that depends.

Daniel Kahneman discusses the topic of intuition in his recent book titled “Thinking, Fast and Slow“. He brings examples for both supporting and rejecting the validity and accuracy of intuition, as a decision making tool. He concludes that intuition is only valid when it is associated with a skill. And to acquire that skill tow conditions must exist:

1. An environment that is sufficiently regular to be predictable, and
2. An opportunity to learn these regularities through prolonged practice

When a situation is subject to a statistical regularity then the intuition can be said to be based on a skill. So, for instance, if a developer is asked for the estimated effort for completing a piece of work, the estimate provided should be examined against the above criteria:

1. Is the planned development sufficiently similar to work done in the past and, if so,
2. How often was this work carried out?

If either one of these parameters is unsatisfactorily answered the chances of the intuitive estimate hitting the mark are low, to say the least.

If you are a project manager early in your career trusting your gut-feel could be successful and propel your professional aspirations into new heights, but only if you are lucky. For most people, trusting their intuition could be a risky proposition, unless that intuition is backed by the conditions outlined above. Make sure you back your professional decisions and directions with the skill and experience necessary for increased chances of success and use your intuition as a backup mechanism only – not the prime tool for making managerial decisions.

Think about it!

*This article was first published in pmstudent.com.

According to Malcolm Gladwell’s bestseller Outliers, it takes 10,000 hours of practice to gain expertise in performance-based fields. We can conservatively assume that a working year is made up of 220 days (the rest is weekends, holiday and other personal and public leave days). We can further conservatively assume that the actual time spend on gaining specific experience is 6 hours per day (with the remaining time spent on non productive or non experience gaining activities). With that in mind, it would take an average person 7 – 8 years to acquire a sufficient level of proficiency in any performance-based area of expertise.

From a Project Management perspective this is important to consider when making recruitment decisions. To understand why, we should examine the meaning and consequences of achieving the 10,000 hours target.

According to Malcolm Gladwell, spending 10,000 hours on any performance-based vocation is required to make the person an expert in that field. If ‘expert’ represents the end of the scale it can be safely assumed that the level of expertise is subject to a periodical growth, either a linear growth in which every 1,000 hours equate to additional growth of 1/10 of the total expertise, or non linear, in which case every subsequent 1,000 hours contributes exponentially more to the overall experience gained. Either way, recruiting a project manager with an experience of less than 7 – 8 years implies recruiting someone with lower capabilities who is not yet fully proficient in the execution of the complete requirements associated with being a project manager. Assuming a linear progression, recruiting a person with 5 years experience would imply 62% of total proficiency, and similarly, recruiting someone with only 4 years experience would imply 50% of total proficiency, etc. If a more exponential behaviour is assumed then the results will be closer to  40% and 30% respectively.

Some job ads look for junior project managers with 4 or 5 years experience. That’s ok, provided that it is clearly understood that the person hired for the position would not have sufficient experience to fully fulfil any of the pre-requisites required for a fully proficient project manager. It should also be recognized that such a person would need to be monitored and mentored in order to ensure they provide the level of service necessary to do his/her job correctly.

Think about it!

I can’t prove it but my intuition tells me that most project managers will respond affirmatively to the following question:

Do you believe your project will end up being a success?

This intuition of mine is not entirely baseless. Known psychological study have identified, for instance, that 90% of drivers rate themselves as better drivers than the average driver.

In our own project management field, the very fact that a considerable number of projects end up in failure (what ever ‘failure’ actually means) is a clear sign that at least a number of project managers (quite a few in fact) start their project endeavour with some level of delusional hopes.

Now, if you are one of those (just like me) who would be willing to bet right now that their next project will be a successful one, shouldn’t you be pausing for a second and asking yourself why the hell do you think you are special? What makes you think you are different? What special skills and knowledge do you posses that others don’t? Like the driver above, should you not at least consider the possibility that your next project, if nothing else, will be amongst the large number of projects of which we read day in and day out, the ones that end up in some form of failure?

The above behaviour is beautifully explained in Daniel Kahneman’s latest book “Thinking, Fast and Slow“. It is a result of a number of psychological effects, most specifically our inability to integrate our knowledge of known statistics into assessing our own position. The ratio of projects that fail is publicly known to be substantial. This ratio needs to be taken as the base rate, as  the standard against which our own project needs to be measured. Now, whether your project is “special” and should  be awarded a different chance of failure is a matter of more contemplation. Being “special” does not necessarily mean that your chances of success are better, as they could  easily mean that your chances are lower than the standard base rate.

Not considering the industry base rate is a self-inflicted deficiency which we are all subjected to. We all read, hear and discuss failures in other projects but fail miserably to see the implications of this information on our very own project – because we are blind to our own weaknesses and our own ‘average-ness’.

The reasons for our irrational behaviour is explained by Daniel Kahneman as follows:

• “We focus on our goal, anchor on our plan, and neglect relevant base rates, exposing ourselves to the planning fallacy.
• We focus on what we want to do and can do, neglecting the plans and skills of others.
• Both in explaining the past and in predicting the future, we focus on the causal role of skill and neglect the role of luck. We are therefore prone to an illusion of control.
• We focus on what we know and neglect what we do not know, which makes us overly confident in our beliefs.”

The take from this is simple. Although you are special (well, we all are) it is unlikely that your project is outstandingly different to all other projects and you should therefore consider your position vis-a-vis other projects. Given that a large proportion of other projects is likely to fail make sure you adjust your estimates such they present a less optimistic and thus more realistic outcome.

Think about it!

Another action packed year is coming to an end and with it comes the need to reflect.

My biggest satisfaction this year has come from being able to allocate sufficient time to reading. In addition to ‘consuming’ and ‘devouring’ large number of blogs, using my News Reader, I have also managed to squeeze in quite a few ‘real’ books as well. My areas of interest included such diverse topics as Technology, Psychology, Science, Rational Thinking and Philosophy. And yes, Project Management as well.

In my writing I have tried to incorporate all these varying disciplines. My key learning this year has been the importance of and the impact that various psychological effects and biases have on our behaviour. This, in my mind, is a much bigger issue, with more extreme impact, than any other factor affecting project performance. Other parameters (like the implementation of an Earned Value Management System, scope management, etc.) are easily learned (although may be difficult to execute) but do not need cognitive adaptation. Being aware of our own deficiencies is a much more complicated concept to grasp, and more needs to be done to raise the awareness about its impact and consequences.

On this note, more on this will be written next year. In the meantime I would like to wish you all a happy and safe new year and looking forward engaging with you after the holidays.

Cheers,

Shim.