quantmleap

These apps will help you crank up office productivity from your smartphone:

1. Project Schedule Free

This app will help you schedule and prioritize your projects and tasks from your smartphone. You can see long or short-term deadlines and projections at a glance on a Gantt chart, as well as group tasks by priority or project. You can compose a Gantt chart on your smartphone and easily export it to .png format for use in a PowerPoint or Prezi on the same day. If you start the day with a commute on the metro, this will help you hit the ground running once you arrive at the office.

2. Dropbox

This is the simplest, most effective networking software on the market—once you’ve shared folders with your employees, simply drag and drop files from any computer into a shared folder accessible by any client or employee with an internet connection. The Dropbox app connects your Android phone to your office’s shared folders, which is immensely useful when facing deadlines or oversights. If you’re up against a deadline and forgot a necessary document at home, you can access it through your Dropbox folder. This app is equally useful for keeping your project teams on the same page; by providing a shared file structure for your projects, you can make sure that everyone is aware of everyone else’s work, minimizing duplication and wasted effort.

3. Skype Mobile for Android

This app can drastically shrink the cost of your inter-office communications. Emails take time, and internal phone calls add up; but if your teams have Skype Mobile, they can send and receive phone calls Skype-to-Skype wherever they have wireless coverage for free. If your office has T-Mobile wireless coverage, you’ll be able to call each other for free almost anywhere in the country. Personal contact builds team cohesion and motivates solid work; the option of video conferencing from your smartphone makes it easier to build real relationships with your team, even when you can’t be there in person.

4. WinScribe Digital Dictation For Android

The difficulty of typing on a smartphone is a fact of life for the foreseeable future, so good voice-recognition software is the only way to efficiently produce large quantities of text on your smartphone. While dictation technology in the past has used clunky equipment, this app lets you securely dictate, transcribe, and review finished documents from your smartphone—making working from your smartphone as effective as working from the office in almost every way.

5. Nozbe

This app connects your iPhone to the comprehensive Getting Things Done (GTD) system, prioritizing and categorizing you and your team’s daily tasks so that every task has the appropriate time allocated, and every hour of the workday has a task allocated. By establishing a single Nozbe account for your team, you can keep everyone running on a unified schedule, coordinating tasks so that your team works together smoothly and efficiently. From your iPhone, you can plan tasks, invite feedback, and keep track of what operations have been delegated to which teams or employees.

6. Outpost 2

This app will allow you to access your BaseCamp management software from your iPhone or iPad. With multi-account support, you can manage more than one BaseCamp account from a single device. You can add or edit milestones, new tasks, and send or receive messages from your team. The app features partial offline support as well, so even when you’re out of your coverage area, you can still access most functions. Unfortunately, serious design flaws have been reported which make this app useful only for short-term goal setting (within 48 hours), but if you use BaseCamp software, this is an excellent choice to make your down-time more productive.

Bio: Jane Johnson is a writer for GoingCellular, a popular site that provides cell phone related news, commentary, reviews on popular providers like T-Mobile.

In a previous post I have made the sweeping claim (based on circumstantial evidence) that many recorded project failures are likely to be a result of a failure in adhering to basic rules of ethics and morality. 

One of the conclusions arising from this hypothesis is that a far greater emphasis should be put on ethical and moral teachings in training, coaching and mentoring project managers. The rationale behind this should be self-explanatory: If ethical and moral failings are amongst the leading causes to project failures, addressing those at the grass-root level should result in an increased likelihood of such behaviours ceasing to exist and, voila, resulting in better project outcomes.

Right?

Wrong!

The reason this hypothetical solution will not work is because it fails to account for one of the reasons why people are ‘pushed’ into making unethical and immoral decisions in the first place.

I believe it is fair to say that most people attend to their daily duties with a genuine attempt to deliver fair value for money while exhibiting socially and professionally acceptable ethical and moral attitudes. When things ‘go south’, individual defence systems are raised and self-preservation kicks in. It is at this moment that people are faced with the dilemma of whether or not to live up to their professional code of ethics and their own value system. Should they live up to the standard set by their social and professional affiliation at a cost of personal and professional humiliation, or not? The dilemma is therefore about contrasting the personal cost versus the external cost (as determined by the cost to the project, the company, the team, etc.). At this point it boils down to the individual’s pain threshold. The lower your pain threshold the sooner you will break your ethical and moral standards; and vice-versa.

With the above in mind we are now ready to contemplate a possible solution to this problem. Reducing the risk of a moral or ethical ‘breach’ can be achieved by attending to one (or two) of the following options:

• Help people increase their pain threshold, or
• Look into ways for reducing the actual pain

 Although it might be possible to help people increase their pain threshold, it doesn’t sound like the ethically correct thing to do. People should not be expected to perform any work that can cause them psychological stress. So I will leave this point without any further elaboration.

Reducing the actual pain is certainly something that is within the reach of every organization. As speculated above, people are driven to deviate from their ethical or moral code by the fear of public humiliation. One of the causes of such humiliation is the fear of being branded and stigmatized as a failed project manager. As outlined in previous posts, this fear results in lack of initiative and in overly risk avoidance attitude. It is also this which makes organizations come up with bureaucratic  rules and procedures stressing the need for ever-more quality assurance gates.

Removing the wholesale stigma associated with failure will achieve a number of objectives:

1. It will result in lower level of QA loading, not directly contributing to the actual success of the project;
2. It will result in greater willingness to take reasonable risk with the expectation of achieving better project results and allowing the realization of greater opportunities; and
3. It will result in reduced chances of personal pain and thus in decreased chances of professionals making unethical and immoral decisions.

Think about it!

Judging by main stream literature one would conclude that the key impediment to successful project management is deficiency in execution skills. With this I mean to include the hard skills progressively elaborated on in such project management guides like the PMBOK or PRINCE2. These include the areas of knowledge, the key processes as well as the tools and techniques required to drive a successful project. More contemporary literature, primarily promoted in leading blogs and discussion groups, expands on the importance of exercising precision while determining what DONE looks like, how percentage compete is to be objectively and correctly measured, the proper and necessary use of Earned Value Management, Monte Carlo simulations, etc.

 If I were to step back and analyze the evidence before me I would easily conclude that the ‘art’ of project management is largely dependent on the skillful execution of a set of technical recipes – the correct  carrying out of which will result in project success.

There is, however, an issue with accepting the above premise. Academic research carried out by Prof. Bent Flyvbjerg, examining transport infrastructure projects worldwide, has concluded that cost escalation is the norm and not the exception, with almost nine out of 10 projects exhibiting some level of cost overruns. It further found that cost escalation has not decreased over the past 70 years (which means that we have not been seen to be doing a better job at estimation in recent years compared with former years).

Contrasting the above with the observation that the number of certified project managers is expanding at increasing rates,  one would have to conclude that there is an apparent logical inconsistency in the lack of positive correlation between the increase in professional proficiency and the continues trend of projects’ cost over-runs.

The absence of positive correlation suggests that this logical relationship does necessarily holds true and thus should no longer be assumed to be a key factor in successful project execution. This, as we shall see later, must have profound implications on the way project managers are trained, recruited and performance managed.

I am personally convinced that the single biggest factor contributing to project failures is lack of ethical and moral considerations. Other factors are more than likely having an impact as well but their severity is compounded as a result of unethical and immoral behaviours. Accepting this as a key contributing factor to project success and failure can explain many of the observations recorded as eliciting project failures. Prof. Flyvbjerg hypothesizes in his research that the reason many projects result in substantial cost over-runs is because the estimates upon which they were approved were unrealistically low in the first place. similarly, sifting through the Ombudsman’s findings regarding Victorian public ICT projects in can be clearly demonstrated that in the majority of the cases, projects were positioned to fail before they even started, due to decisions that were blatantly either unethical or immoral. 

To summarise: In this post I have attempted to raise consciousness about the impact that ethics and morality have, in practice, on projects’ success or failure. These factors are not being given their due importance in this context and I would suggest that incorporating them into future research will find that behind spectacular failures there will frequently be hidden unethical or immoral decisions.

I will further elaborate on this point in a future post.

In the meantime…Think about it!

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.