A Quantum of Planning
Copyright © 2015 Roberto Lofaro http://www.linkedin.com/in/robertolofaro All rights reserved. ISBN: 150867342X ISBN-13: 978-1508673422
CONTENTS “Connecting the Dots” series .................................................................... I Re-use it!................................................................................................... II A Caveat ................................................................................................... III Why #QuPlan ............................................................................................ 1 What is a project? ................................................................................. 2 The impacts of tools and methodologies ............................................. 4 1. Today .................................................................................................... 5 1.1. Why planning is still relevant......................................................... 5 1.2. Qualitative vs. quantitative planning............................................. 8 1.3. Planning and stakeholders .......................................................... 11 1.4. Planning and team building ......................................................... 12 1.5. Project-level stakeholder management ...................................... 13 1.6. A systemic perspective ................................................................ 14 1.7. Continuous process improvement .............................................. 19 2. Tomorrow ........................................................................................... 23 2.1. Coping with the future ................................................................ 23 2.2. The social enabling effect of technologies .................................. 24 2.3 A XXI century definition for “project”........................................... 26 2.4. Projectify your organization- the app paradigm ......................... 28 2.5. Corporate planning and swarming .............................................. 32 Appendix A. Software Classes Comparison ............................................ 37 Appendix B. The Online Component ...................................................... 41
“CONNECTING THE DOTS” SERIES
In my business activities, and even before in politics, sales, and during the compulsory service in the Italian Army (Artillery Specialist group at a Divisional level, within a mechanized artillery division), I often ended up doing just one task: connecting seemingly unconnected “dots” (people, information, resources, etc.). The aim? To present the results to a non-specialist audience, thereafter acting as an interface, communication channel, facilitator, negotiating between multiple parties, usually to help first identify a target destination and pattern for change, and then helping to steer the organizational ship (be it a small team, or even just an undecided manager or customer) to the intended destination. This usually involved a lot of reading, listening, thinking, and… “thinking as if I were wearing somebody else’s shoes”- before writing. Until a decade ago, these “connecting” activities weren’t visible online, also if I had registered my first domain (prconsulting.com) in 1997 (the same year as Google!). This series has just a common thread: repeating that “connect experience and knowledge to initiate change” approach, but focusing each time on a specific issue.
If you visit my Linkedin profile (address provided at the top of this page), you can find a link to a 1-page presentation of a management workshop on change called “Are You Ready for Change”. It is just a “placeholder”, akin to what you do when playing the game of Go (Weiqi) to “mark the boundaries of your intended territory”, but it should give you a hint of what I am currently preparing. As usual, my concept of copyright is closer to “Creative Commons for Attribution” than anything else- practical solutions for realistic challenges. Therefore, you can reuse the material contained here, online, or in any link to my previous (or future) writings that I will provide you with, either directly, or because openly accessible. There is no limitation: if you think that it is worthwhile, you can also build up your business around that (as some consultants, university professors and political or marketing operators did in the past). But you are to quote the source, so that others too could derive from my material without having to pay a derivative author (you) “royalties” (including being made to look as if they were copying you) for what you didn’t originate in the first place. If feasible, add also a link to the original material, send me a copy of your derivative material, and let me know if you would like it reviewed. II
#QuPlan – A Quantum of Planning
This page should be accessible for free on Amazon: if you are looking for a book on the “technical” side of project management, keep looking. If, instead, you are looking for something that delivers an overview about present and future issues and impacts related to programme/project/activity management, this might help (I excluded portfolio management, as the focus is slightly different, and it would have expanded this small book too much). This short book is basically a “brainstorming case study” that will be used in a new service, as it covers issues that nowadays are part and parcel of any cultural, organizational, technological change. Along with the book, you can also find online additional material built around a compliance programme case study, released in “episodes”. You can also refer to the books that I published1 on Amazon and Kindle, books that you can read online for free on Slideshare2. Your comments and suggestions are welcome3. 1
In our age of over-specialization, we keep updating only what we learnt before, assuming that it will keep being relevant forever. Pity that this is a mindset that was relevant in a rural era, when knowledge could be transmitted from father to son- with minimal changes. Urbanization increased the number of people that have to depend on others to deliver the basics needed for their “life support” - and enabled a significant part of the population to specialize4, while creating the need and opportunity for activities that involved more people and various specializations to join forces and deliver a unique result: projects. Project management is one of the areas where I saw most changes within continuity since I had in the early 1980s my first activities involving more people and resources. Changes, because obviously now many of the “building knowledge blocks” of a good project are available to anybody willing to spend some time listening and reading before talking, writing, or doing anything. Continuity, as, in the end, if you remove all the brouhaha and lingo or “turf wars” about which methodology is better, or which tool should be used, there are few elements that are consistent across the board. 4
What is a project? According to the 2014 edition of the P3O Guide5, a project is “A temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case”. The valiant attempt of that anodyne definition was to avoid entering a quagmire of overlapping yet diverging “methodology tribes”. I am used to plan with constraints on resources, timelines, budgets- or all of them: therefore, I often dissented from some self-proclaimed advocates of the “end of planning”. If you can work with unlimited time and resources, and budget isn’t a concern, probably you will seek perfection- and your “no limits” project will turn into a series of projects. In information technology and engineering, this is akin to keep working on the perfect set of features before releasing anything. Obviously, that could be the real purpose of a project, i.e. keeping people busy. I consider “business” also government or non-profit activities whose results, products or services are provided to somebody else, instead of being done just for the self-gratification of those involved. Some ideas of the “agile” movement that started in the 1990s were actually more provocations that guidelines- albeit I saw more than once projects that, while claiming to be following a specific methodology (both agile and “traditional”), simply expanded to absorb any resources available: the “blob approach to project management” (from a 1950s movie). At the same time, I actually saw the benefit of introducing a projectorientation within “business as usual” activities- but this will be discussed within the chapter on the future of project management. Whatever methodology you choose, your project has to start and end (or be halted(scrapped: few projects turn into zombies). 5
“Portfolio, Programme and Project Offices Pocketbook”, 2013, TSO, ISBN 9780113314430
#QuPlan – A Quantum of Planning
To keep this mini-book mini, I will add once in a while references to Wikipedia pages- so, you can follow the “moving target” of standards. Anyway, there are few elements worth considering, while introducing any change including an alteration to your own way of doing: any methodology implies a culture on how roles should be distributed, and often also on how people are managed and motivated. Sometimes you do not make a formal choice to adopt a methodology, but “inherit” an embedded methodology introduced by new Enterprisewide tools (e.g. SAP or other ERPs), new business processes (with and without tools, e.g. CRM and SOX), or just through the acquisition of a new customer that requires compliance with specific rules (e.g. ISO9000, JIT). I prefer to share a framework of reference that is much older (published in 19966), but based on a 10-years research, and that, in my experience, is still relevant (the “payoff” under each box is my adaptation):
To rephrase from the book: - Information Economy: Making a Business of Information - Information Society: Balancing competing Values and Interests
“Information and Communication Technologies – Visions and Realities”, 1996, Oxford University Press, ISBN 0-19-877496-6
The impacts of tools and methodologies The picture in the previous page is probably self-explanatory, but it restates something that is often forgotten in our data-centric times. If you want to deliver something (the “production” box), you are trying to convert a vision into a business- and that implies taking care of the social side, as you cannot deliver unless at least you motivate those involved in production, and have the approval of some of the stakeholders. Any change that is spread across multiple organizations and society eventually generates a need of “governance”, i.e. setting common rules; ideally, if that is done before change starts to emerge, it is called a “policy”, “strategic direction”, etc. But even policy sometimes is a “fixing” after reality changes (e.g. flying drones). At the same time, when you try to introduce a change, e.g. to deploy the results of a project or change initiative (the “utilization” box), a “big bang” is what everybody would like, but in most cases is more a matter of defining appropriate patterns of change, sometimes “big bang”, sometimes “slow phase-in (the new) and phase-out (the old”, with some overlap. Finally, also if your change is aiming to impact just what you do within your own organization’s corporate boundaries, any behavioral change pattern will eventually have a social impact (the “consumption” box): if IBM’s Watson could say that few computers would be needed worldwide, nowadays we can shop for a fridge that actually comes with an onboard computer, the latest car models have dozen of computing devices on board, and we are gradually getting used to interact with home appliances and cars, instead of just using them. Obviously, it would be desirable first to have some governance in place, then production that takes into account the patterns of change required for optimal utilization, and finally consumption once those patterns have been tried and tested within “controlled environments”- but, obviously, that’s the difference between engineering and reality. And project management is the art of delivering and communicating a vision while coping with reality (ranging from risks, social/stakeholder acceptance, to changes in the business or legal environment).
1.1. Why planning is still relevant There can be no “project management” unless there is planning. Nonetheless, the title of this section is partially misleading, as it would have been more appropriate “is more relevant now that in the past”. I remember, in the early 1990s, a CMM7 assessment that, on project management, listed from a scale of 1 to 5 the level of maturity of any organization, starting with a 1 when the project manager was a demi-god, and ending up with a level 5, where (s)he could be (sorry for the shortcut) more appropriately described as a “cog in the wheel”. Or: the optimum of project management, within a perfectly “learning” organization8, could be achieved when each and every project manager is able to “seed” her/his own activities through a perfect store of accumulated knowledge on previous projects, and can contribute, while the new project is ongoing (and not just at its end) to “tuning”, “improving”, “augmenting” that store of knowledge. Obviously, you have to do more than just managing projects. 77
Senge “The Fifth Discipline”, 1990, Doubleday Business, ISBN 0385260946
Unless you were doing your business on Mars, since the 1990s you heard more than once about “Lean”, “Six Sigma”, “Kanban”, “just-intime”, and maybe even “World Class Manufacturing” (WCM for short), which basically collects them all (and more). The key issue with all those “buzzwords” is that they assume that you will “tune” your company and its processes continuously to what is needed now, and then keep improving. What is relevant today will not necessarily still be so tomorrow, and certainly what was relevant yesterday was set up for a different environment. If anything, just because when it was set up, you did not have the knowledge derived from experience within your environment (it didn’t yet exist). I used, sold, designed, delivered methodologies and processes in the past: but I always found that, no matter how good is your starting point, a preliminary assessment of the existing cultural environment is a basic need. There is a side-effect on what is often confused with an optimization drive, while it is not: as you optimize what in reality is obsolete, while instead the aim is to both optimize and innovate your “way of doing”. Many courses on methodologies (not just project management) still talk about “removing the silos mentality”, where each business function thinks vertically and ignores the others, as if that were “new thinking”. Sorry, but already when I started officially to work, in the 1980s, most companies had cross-disciplinary teams, and sometimes had something that is de facto compulsory if you want to be “lean”, “WCM”, etc.: do not think about your corporate boundaries as the boundaries of your activitiessometimes a penny saved or spent upstream is worth a dollar downstream. You need to think “strategically”, and consider also the governance of your interactions with third parties. As in any negotiation, you can think short-term (the stronger or more convincing negotiator carries her/his way), or think about long-term sustainability (the stronger has more negotiating power, but still has to have the other parties as willing participants in future activities).
#QuPlan – A Quantum of Planning
Moreover: in our overspecialized social environment, many companies de facto externalized even activities that they need on a routine basis (the “business as usual”), and most large businesses would be simply unable to work if tomorrow their suppliers and vendors for services, components, products were to disappear. Yes, the old “command and control conglomerate” doing everything within its walls from A to Z is still around, but not very popular- and hasn’t been popular for decades. And your planning? Has to consider that having a look at keeping your suppliers into the loop, and understanding where they are heading to, can be critical to the long-term sustainability of your own business, and probably also to its short-/medium-term competitive advantage. Therefore, simply starting a project the old way, assuming that you can delegate to one omniscient person the role to create a perfect plan that then will be delivered as if it were cast in stone certainly was a dubious assertion long ago, and it is even more so now. You need project managers that have more than just technical skills, if you want them to be able to interact with others (including competitors- as many company still use the “divide and rule” or even the Yeltsin’s management style9. Which skills? Recently I was asked during an interview what was the single element that I consider important for a project manager (it was for PMO role within activities potentially involving M&A). I think that it is appropriate, once in a while, to heed the advice of that politician who said that you have to answer the question that you would have liked to hear, not the one that you heard. In my case, I answered “not one, but two: communication and prioritization”. Therefore, now it is the appropriate time to switch to outlining the difference between qualitative and quantitative planning- and associated side-effects. 9
Larrabee “Foreign and Security Policy Decisionmaking Under Yeltsin”, 1997, Rand, ISBN 083302485X
1.2. Qualitative vs. quantitative planning The first time that I was asked to prepare a budget and plan for an IT project, I had been just hired- but I had already had experience in resourcebased planning, first for political events, then in the Italian Army, for field exercises and that sticky issues- rotating the mix of people allocated to duties that nobody wants to do, plus services that everybody wants to, while coping with the “unexpected” that, in a conscription army, is even more common than with professionals. It was a “by-the-book” planning approach: I was provided tables with “standards”, and quantitative elements to consider, and had to apply the “tea leaves” to, say, add X days for each bit of software that had a screen, produced a file, and was considered of complexity Y. To make a long story short: that budgeting and planning came up with few thousands “man days” (as they were called back then), split across different roles, and obviously projected on the timeline (there were few constraints on delivery time). It was useful- and more or less correct, as the final results were in line with the original budget and schedule of the activities- a proof that planning with finite resources is just planning: having done it extensively before, I needed just to get the specifics of the environment to make it right. A quantitative planning exercise is relatively easy- the more experienced you are (which I assume to mean: not that you delivered X times similar projects, but that you delivered Y different types of projects and learned from each one of them), the less you are baffled from endless variances. Also because, the more variety of projects you had, the more you understood that, no matter what hands-on expertise you had (not just IT, also in other kinds of projects or activities), it is better to involve, those who are still working in the field and can be defined “subject matter experts”. What had been outside my scope was the qualitative side: - is this what the customer wants? - by when does (s)he want it? - what should be delivered when, according to business needs? - what is the “business politics” involved (it impacts on prioritization)? - and so on, and so forth.
#QuPlan – A Quantum of Planning
Appreciating the qualitative side of planning requires developing two skills, communication and prioritization, that are often neglected. You might have been selected for that PM role due to your more “technical” skills, but unless you are able to communicate and prioritize, chances are that you will be unable to manage the project successfully (and I saw and heard of projects running years beyond schedule). Sometimes, I found myself in planning meetings (not necessarily when I was the project/programme manager) where experts leveraged on their expertise and experience in what qualified them as experts (the reason why they were invited), to push through business choices based on a “hunch” that they derived not from the business environment at hand, but… other customers that they had worked on! It is better to clearly differentiate between the quantitative and qualitative side of planning, and facilitate the planning activities by ensuring that, while contributing to this effort, each contributor adds value to the effort. I know that some of my “agile” friends would disagree: but I generally agree with De Bono’s “Six thinking hats” approach- i.e. there is a time for everything, and you have to know not only when it is the time for a specific role, but also what you can contribute to that role. And this applies also to those few around who assume that planning is cast in stone, and no matter what, you work through it end-to-end, and postpone any alteration or changes to later. Actually, I would suggest to the latter kind of zealots to read few history books, notably on past wars, to see how, in reality, plans (and its sibling, logistics) lead to success only if coherent (and coping) with reality. The dichotomy “qualitative vs. quantitative” isn’t to be solved through a sequential activity, hence the recap of the De Bono’s method, not as “the” reference, but as an example of a collaborative decision-making approach (you can follow others). The value delivered by project management frameworks (more appropriate name than “methodologies”) such as the latest PMI/PMBOK or PRINCE/2 is mainly in the shared lingo and “discipline” it brings in your project definition and management activities.
As an old saying went, any long journey starts with a first step. It is something that should be commonplace today, but it is worth remembering something on the “quantitative” side _ you can define a “quantitative knowledgebase” for planning activities _ that doesn’t imply cut-and-paste project management _ before any project starts, you should identify which rules apply to it _ if a project repeats perfectly a plan for another project, ask why _ each project should monitor the environment it is working in _ a project run in a vacuum often delivers results with no customers _ whatever tool you use, it is a tool: hack the tool, not the plan And on the “qualitative” side: _ qualitative knowledge is business- and organization-specific _ qualitative assessment implies looking at the big picture _ qualitative doesn’t necessarily mean “logical choices” _ quality is the side-effect of a process, not a product _ quality is a continuous journey: the budget and purposes are the limits _ quality should be sustainable, not a “life-or-death” once-only effort. The weakness of both “agile” and “non-agile” methods? Team building: - for Agile, when skills and experience differences are ignored - for non-Agile, when trying to choose mono-dimensional people10. In my experience, the success of a project wasn’t really a “miracle man” project manager (even when I was the project manager and told that I had made miracles by my team members that I had met for the first time on that project), but in appropriately following the guidelines listed above. Also when your team isn’t optimal, you can still deliver a project if you can manage communication and prioritization- both toward the team and toward other stakeholders. If, as stated in the introduction, “a project is a temporary organization”, then it needs a purpose, and this implies that planning should deliver something more than a plan that can be fulfilled- but also buy commitment from most of those who will be affected from or using the results of the project- whatever your methodology11. 10
Marcuse “One-Dimensional Man”, 1991, Beacon Press, ISBN 0807014176
Interesting report from Forrester “Water-Scrum-Fall” http://issuu.com/addinquy/docs/water-scrum-fall_0 10
#QuPlan – A Quantum of Planning
1.3. Planning and stakeholders Having a “by the book” project manager obsessed with a Gantt, PERT, CPM etc. isn’t enough, if (s)he is unable to communicate with stakeholders. Furthermore, (s)he must understand that keeping to a plan isn’t enough, if the underlying assumptions might have changed. The first step is recognizing that “manager” in “project manager” is not just a title- and that too many project manager are focused only on the administrative side, even obsessed with it (the “but we are on schedule”, or “we kept our milestones” attitude). Actually, I prefer the term “project leader”: it has to be tuned according to the mix of skills and expertise contributed by your team members (both people reporting to you, and those involved with you). Yes, I can think of no single project in which I skipped involving the appropriate stakeholders- also when I discovered them after taking over a project- in some cases, it was that the only reason why adjustments were accepted- they had been kept within the communication loop. It isn’t a matter of a mere bureaucratic “cross-checking” on a bullet list, but of hearing before talking, and having a degree of natural empathy that, while can be complemented by experience, cannot be built in a day. It can either be innate (doubtful), or become a second, instinctive nature- I never trust those working for me (or that I am working for) who seem to have “empathy on demand”, i.e. active only when needed. The “empathy switch” type risks being perceived as manipulative, with an attitude that can wreak havoc: once discovered, rebuilding goodwill can take ages, as everything that is said and done comes under suspicion. Example: silent project managers that suddenly start spinning emails- a typical sign of “sand-bagging” before a flood of delays. In most larger organizations (or those that “inherited” rules from others, e.g. by hiring former employees of consultancies or larger corporations) there are guidelines not just on stakeholders, but also on team membership. This subject is worth at least a short digression.
1.4. Planning and team building In most planning exercises, there are external reasons on “why” somebody is to be included on a team. Sometimes it is only to ensure that they cannot later claim to have been “kept in the dark” about the project, but in other cases the reason for their presence is what could be called “corporate politics”. I am frankly skeptical when I see the definition of a project turned into a career-building (for internal resources) or budget-winning (for suppliers) event, as, again, it risks affecting the viability of the project. Moreover, when that “team expansion” extends to the actual project. In my view, “team members” is a limitative perspective: there are those who will be part of the team (e.g. subject matter experts full-time or parttime), those who could influence, but there are others who should in a way or another be associated and “kept in the loop” with a team (and I am not talking about the “standard” sponsors, etc.): _ “influencers”: whoever can affect the visibility and smooth ride _ “evangelists”: there are in any organization- sometimes too “political” _ “traditional”: look at e.g. MSP12 for the table of roles in each phase _ “litmus test”: real-time check on evolving acceptance of your project A further, often ignored category is that of the “influenced”: they are difficult to identify, but could act as “grassroot sponsors”, i.e. building the social infrastructure needed to have the results of your project used, and motivation within their peers (or, indirectly, peers of your sponsors) built while the project is ongoing. If a project introduces a new technology, process, or alters in visible and significant way the “status quo” (in whatever dimension), the latter are actually a kind of “silent majority”: you can ignore it, but then you will pay when you will need them most- better to find indirect way, agreed with your project sponsors, to create a “communication momentum”. Unless, of course, your project has to be a surprise- in that case, probably “communication” and “prioritization” guidelines will trash any publicly available methodology you can think about. 12
“Managing Successful Programmes 2011”, 2011, TSO, ISBN 0113313276
#QuPlan – A Quantum of Planning
1.5. Project-level stakeholder management The reason why, also in my activities since 2008, I referred often to the MSP framework (nominally focused on programme, not project management)? It is the only one that delivers a seemingly disproportionate space to stakeholder “management”. Actually, I prefer to avoid using “stakeholder management”, and say “governance” or “coordination”, as I observed way too many managers converting “stakeholder management” into “stakeholder handling”. As I wrote above, being manipulative to support your own interest is something that exacts a heavy price when you would need your stakeholders to be collaborative. Stakeholder management required adopting mainly a long-term perspective, unless, of course, you have been hired just to solve a crisis, and can expect to be released as soon as that crisis is solved (it happens). In my experience, again, prioritization and communication (in this case, reversed) are what should guide you: project managers who try to be the best pals of their customers often forget prioritization and their own role for the sake of the personal relationship with stakeholders Sometimes, it makes sense to organize events or workshops to create a shared lingo between all those involved. As an example, when I was designing and delivering a methodology for an outsourcing/BPO company in the early 1990s, eventually I identified the need for some “extracurricular training”, and the CEO approved the proposal to scout around for a supplier of “soft skills” training. I identified the training needs through the first sessions and activities in the training programme that I was delivering, but I did not want to be involved on the additional training focused just on “soft skills training”, as it can be sometimes confrontational to deliver behavioral change. I mapped out the needs and helped to select and manage the supplier, but I stayed out most of it, while instead adding knowledge transfer to stakeholders “embedded” in on-the-job coaching activities on various projects. It always pays to adopt a systemic approach. 13
1.6. A systemic perspective When, in early 1990, I was asked to help assess the potential of the partners/shareholders of a small system integrator, I actually delivered a batch of seminars that I deemed useful to develop not just the skills, but raise the questions that each one of them should eventually be able to solve. The range covered from the obvious (interviews, meeting facilitation), to the less-than-usual (discussing types of projects and information systems, and the cultural aspects associated with each one of them)13. When I recently looked at that material, I found it still moderately useful, but I think that a similar approach can be used by any organization large enough to have had a couple of generations of project managers, i.e. to have had already to cope with “cross-generational knowledge-transfer”. The critical issue is that you have to keep mapping out who, when, how should be involved across the whole life of a project, from “scope identification” to closing down and thesaurisation of the results. A couple of steps are often forgotten, and should be routine for any project, anywhere, no matter how short or how long, or how large your organization: _ “thesaurisation” implies knowing who is going to be the audience _ “communication planning” across all the life of the project _ “entrepreneurship” as any project has to be “sold” before it is ready. Let’s say that you have a project. Let’s say that you did your homework on who are your stakeholders and what they should be involved in, and what should be asked from or provided to them. Add a further element: what could affect your project or the usefulness of what, eventually, it will deliver- to the overall organization, and not just the direct customers. DRAFT A TIMELINE FOR YOUR PROJECT BEFORE READING THE NEXT PAGE.
Available by January 2016 on http://www.robertolofaro.com/books
#QuPlan – A Quantum of Planning
The weakest point is usually communication planning, something wellknown to those working in politics and entertainment event management. Did you think also on how to manage the “phase-in”/”phase-out” of each role within each step, and how to track expectations, results, feedback, any “recovery actions”? Probably no- as most project management nowadays is so resultsoriented, that forgets that results are delivered by and to people, and that people have their own motivation and purposes, and that both motivation and purposes evolve (re-read the introductory chapter of this book). I met project managers who were really good at the technical side of their activities- but were sloppy on the administrative, documentation, and relationship-management side. Frankly, a significant amount of their time more often than not risks to be spent to play the “hero that saves the day”. Long-term, a business liability, as that adrenaline-building attitude is addictive, and I found cases when crises where generated by simply avoiding boring but much needed preparation activities. Obviously, most stakeholders can easily spot the “easygoing, informal” project manager that suddenly turns into a perfect bureaucrat/lawyer, flooding their mailboxes with email messages. If you read my previous book on BYOD14, you will certainly recognize the “line of thinking”- but it is just appropriate, as in any “connecting the dots” the ability to see the forest where others are barely considering individual trees, not even thinking about being in a forest, is a compulsory skill. In that book, I referred to: _ Devices _ Users _ Services _ Channels _ Information.
Again, a systemic perspective while managing a project assumes that you keep your eyes open, define a method to monitor your progress, and forecast any potential impacts on future activities (i.e. you need a quantitative and qualitative baseline15 matching your communication plan). Whoever read my online writings since 2003 knows that I dislike “featuritis”- we use barely a fraction of Microsoft Office or Microsoft Project features, but all the others are always in the middle of your way. Admittedly, Microsoft made a first improvement with the 2010 versions of its software packages, and further improvements with the 2013 edition: I like the “timeline” feature, to summarize your project end-to-end, albeit it is still primitive and Microsoft-annoying, i.e. seemingly designed by software engineers trying to cover all the bases, not thinking about “usage patterns”. Maybe I am antiquate/obsolete (“antique” would be appropriate, as I recycled and adapted approaches that were old even before my birth!), but when I was teaching in the 1990s as part of my change job I said that, timewise, few elements should be looked at in any element: speed, velocity, acceleration, and direction in your budget consumption. Obviously, my mathematical-savvy customers (many had degrees in math or sciences) said that I was recycling a bit of calculus16. But I saw first-hand in the 1980s on PMO activities how the typical “progress report” (“we used 80% of the budget to deliver 60%”) doesn’t tell you a useful story on what could happen- it lacks context.. Also, beside trends, you have also to consider the complexity of what is yet to be done (the “Pareto 80/20”). Modern methodologies contains charts such as the “burnout”17 (official name: “burndown”) that deliver the same information, but, coming from a quarter of century of decisions support system models and business intelligence reporting for non-IT managers, I saw that that isn’t systemic enough. 15
#QuPlan – A Quantum of Planning
As discussed within the introduction, and repeated often but not often enough, your project isn’t delivered in a vacuum. Also if you have X resources allocated (moreover, when they are external resources), they just don’t sit still waiting for you. It is the beauty of “just-in-time”: nobody keeps resources available for potential use anymore, and as soon as you let a resource idle… a different use is found. I saw and was on projects that took on board risks just because there had been attempts at “optimizing revenue and resource allocation”… by removing them also if already paid and allocated. Therefore, thinking systemically implies considering the whole supply chain involved in your project, and how to keep the level of resources needed when it is needed, without excessive “warehousing”. I like to share once in a while an example that I was told in Zurich by a technical resources manager for a large software+hardware company (I will not tell which one), referring to a 1990s case. He told me that a bank in the City had asked to provide a technical expert, as required by their insurance, to be on standby but in their office- I remember that the cost was over 2000 GBP/day. Months later, the manager received a phone call by his technician that had been dropped on the customer site: he complained that he had played “solitaire” on his computer in the server room for months, and had had enough (yes, it was pre-Internet). He called back the customer, and was told that they paid, and if was fine with them, why should the supplier complain? It was what was required by the insurance, and they had it. The reply: but after six months playing solitaire, he will not be able to do what needs to be done when needed. Obviously, that wasn’t the best approach to managing that resource: unless you start looking for assignments for experts in playing solitaire. A simple way to monitor the evolution is to identify, before the project starts, the communication channels that are needed. 17
Then, you have to structure them accordingly and “synchronize” your communication exchanges with each specific channel and its evolution. It is obviously an additional effort: but, frankly, I saw way too often what happens when this step is skipped (yes, it is boring, to keep being informed on what others that could affect you are doing). It happened often enough, that already by mid-1990s I had designed and prototyped an application framework to build “alert flags” and keep being informed; the first practical use was an experiment with a partner that was then to support the further development, on using the framework to enable large companies to know when software patches/updates were available for a series of computer configuration types that they had identified- a kind of primitive “evolutionary ICT asset management” built on a knowledge repository. When you are lucky, your project is part of a programme or actively managed (i.e. not just the budget expenditure) portfolio, where there is already staff allocated to keep and manage such a communication channel. Nonetheless, it should be up to the “operational management” (the project manager and his team members), with a better understanding of the practical impacts, to keep track of such information, not to a centralized office that doesn’t necessarily know in detail what your project is doing. In some practical cases, where there were multiple projects and this “centralized communication” was the choice, I helped to ensure a “quantum approach”, i.e. a single issue both generated communication toward the centralized staff and alerted a regional subject matter expert, that then added to the “monitor pipeline” what happened, to ensure that nothing was “lost in translation”, but kept quiet otherwise (to reduce the email traffic- email exchanges are a productivity sinkhole). In other cases, when there is no programme (maybe because it is out of your project that a programme will emerge), or portfolio management takes care only of financial issues, it is an unavoidable duty of the project manager to at least maintain (if there is a PMO or PSO) or even build (if there isn’t) appropriate communication channels. As for risk management… I think that if you are a project manager, there are plenty of resources online (e.g. a free overview course online18). 18
#QuPlan – A Quantum of Planning
1.7. Continuous process improvement So far, beside the hint at “thesaurisation”, I referred just to a single project- extended, through the system perspective, at its impacts. There is obviously another dimension, that over the last few decades involved into (of course) another set of methodologies, frameworks, etc. For its general perspective, it is worth reading the P3O material19, but also consider project support and related organizational support as a service provided by the “organizational infrastructure” to those temporary organizations that are to deliver “products” (i.e. projects), and therefore having a look also at ITIL is time well spent for project managers, at least to look at concepts on knowledge and configuration or product/service catalogue management20. . Why it is useful? Because you can manage the impacts only of what you know- and, in the end, the results of any project should be able to be added to the “service catalogue” of the organization. More than a dozen years ago, I was asked to be (as usual, part-time) project manager (but my team was full-time) on a project aiming to audit the knowledge management and retention practices adopted by a portfolio of projects and services. One of the first tasks that I assigned myself, along with the usual identification of scope, content, plan? Design and introduce a database to categorize information that we were collecting, for further use (through knowledge transfer to the appropriate offices within the customers’ organization), and electronic note-keeping. In my previous experience with auditing projects and activities, as well as crisis management, support to projects, and also working with CFOs and Financial Controllers, I saw that keeping track only of the positive choices isn’t enough. Things might evolve, and negative choices might need to be overturned. 19
“Portfolio, Programme and Project Offices Pocketbook”, 2013, TSO, ISBN 9780113314430 20
“ITIL® Foundation Handbook”, 2012, TSO, ISBN 0113313497
At the time, I had studied neither ITIL nor TOGAF nor FEAC, but I had already had few years doing similar projects Say what you want, but from what I saw around, “asset management” (not in financial terms) and “knowledge management” tools are most often purchased and either neglected or used more as a dump than a repository. The point of having a repository is not just to store relics within it, but to have something that you can extract value from, analyze, and use to seed activities focused on improving your own ways of doing things. A common complaint by senior business users (or subject matter experts) used to be that once in a while they were invited to meetings where they were asked the same questions that they had been asked by other project teams- and this also after a “knowledge management system” had been introduced. A practical example. Also if I had left the “hands-on” side of business intelligence a decade ago (I will briefly have to resume it soon to write another book, about the future of business intelligence), few years ago, while working as PMO, I was involved in having a look at which license would be needed for which users. As I had worked also on the vendor side of DSS/EIS and business intelligence software since the late 1980s, I know “a bit” about optimal allocation of licenses- as, while any user would like to have the “top license” (call it “power user”) with all the features available, that proposition would be prohibitively expensive, and potentially dangerous (as power user tools allow to more easily share with your own “public” not just raw data, but also data that they derive). In software packages as in life, great power requires great responsibility, and that comes only with training, coaching, and continuous familiarity. If you were to give a software tool with too many features and too many possibilities to make a mess (also if just in misleading analysis that is then shared across the company) to under-trained, occasional users, you would create more work just for… all those supporting them, generating a negative feed-back on both the software and the support. So, the first step was identifying the needs of each “type” (profile) of user, and propose am appropriate licensing pattern. 20
#QuPlan – A Quantum of Planning
Maybe you aren’t into software, so I will use another example, on organizational development. I was asked by a large customer that had acquired a group of companies whose services were overlapping with their own to have a look at how services, products, and people could be blended within a new organizational structure (I had to work on the latter as well). In Italy, decades ago there was a maze of contracts at the national level, generally by industry, but sometimes focused on specific roles (e.g. managers or middle-level managers) within each industry. Merging two groups of companies therefore wasn’t just a matter of defining an optimal organization, but also of checking which contract with which perks should be adopted. In that case, I had to first collect the information on which contract was applied where, the general business of each unit, and see on a comparative scale what would happen, which implied also looking at what a) each contract entailed b) each business unit was focused on or could be focused on c) other additional information. As you can see, in both cases the first step toward improvement was having a “knowledgebase” that contained both “background” information (on the software or on the contracts) and “application” information (on what that was used or to be used for). Building a continuous improvement knowledgebase can become a cumbersome and expensive exercise, and I can divert you to another book (on knowledge-based organizational change) that I published two years ago, available online also for free21. A short, simple, and intuitive guide on that side is to have a look at a book describing how the “information bureau” of a newspaper was set up in UK22- in the 1970 (of course- replace paper files and folders with diskbased variants); those concepts will be used also within the online business case supporting this book. 21
Weiner “Answering Any Questions: How to Set Up an Information Office”, 1974, David & Charles, ISBN 0715364782
2.1. Coping with the future This book started with a section on “what is a project”, and it is just appropriate to paraphrase and now move onto “what will be a project”. Let’ s start with the basics, repeating the “standard” project definition,23, “A temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case”. What will be the difference in the future? Think again about “temporary”, “purpose” “delivering”, “agreed”.
Yes, I think that business products and business case should still make sensebut everything else will have to be reconsidered, including the basic concepts of “budget” and “scope”. If you read my previous books, you might think that I am obsessed with “swarm-based” organizations: but I think that this is what Big Data and the future Internet 2.0 will enable.
“Portfolio, Programme and Project Offices Pocketbook”, 2013, TSO, ISBN 9780113314430
2.2. The social enabling effect of technologies When we talk about Big Data, we are often referring either to the positive (new services, just-in-time for everybody, including your own home fridge), or the negative (no privacy). But, as I discussed in a previous couple of books on social networking and BYOD/IoT24, the picture isn’t black-and-white, it is more nuancedand colorful. First, the infrastructure: it is only a matter of time, but Internet as we assume it to be will change. Unless it is willingly transferred to a global supranational entity, such as an evolution of the UN that goes beyond the multilateral approach that is often followed (despite what the UN Charter says), sovereign states are bound to re-assert their own individual jurisdictions. The more businesses will become “virtual” (more about this later), the more states are at risk of being unable to generate enough revenue to sustain their own social and physical infrastructure. Fairness would require obviously a kind of global “corporate citizenship bill of rights (and duties)”, but no authority with a global taxation power is foreseeable in the near future, and therefore states are, in the end, to fend for themselves. As shown by the “net neutrality” diverging choices between the USA and the EU in 2014 (the former affirming it, the latter declining it into a kind of “you can make a difference between business and non-business”), having a global infrastructure without a global regulator eventually turns any choice affecting it into a political choice catering for internal political aims. And while corporate citizens gradually acquired rights and duties, they still have a disproportionate voting impact- it is certainly not a “one person, one vote” system. While I understand the business logic of the EU choice on net neutrality, it is stuck in the past, as I think that the distinction between “business” and “non-business” is about to disappear. 24
#QuPlan – A Quantum of Planning
If the infrastructure is neutral and accessible, and if anybody is connected 24/7, both by choice and as a side-effect of using devices that are “embedded” in everyday life, any personal or business action will generate information and could consolidate experience into knowledge. We still lack a storing mechanism for this “emerging” knowledge, but looking at my past 25+ years in business intelligence and its precursors (as well as a prior but pivotal digging into Artificial Intelligence, PROLOG, Expert Systems, and decision-making theory), I saw how the availability of information influenced decision-making, or at least decision attitudes. Internet 2.0 should bring about the ability for countries to build “virtual borders” (e.g. like e-stonia25), but, also if not enforced, will enable another feature: perfect traceability of any data exchange- and without the need of a NSA “piggybacking” on the fiber-optic cables or exchanges of telecommunication companies. It is interesting to consider how the experience of Estonia (the ecitizenship for both individuals and corporations) could evolve- and be replicated elsewhere. Imagine that whatever you do- personally (via a PC, smartphone) or by using something (from how often your open your fridge, to how often you wash a specific garment, or wear and walk with your favorite pair of shoes) leaves data behind, and is able to exchange those data. Once everything is traceable, you can actually turn that “traceable” into “tradable”: if whatever you do generates data that you can aggregate to influence what you do, but you will eventually also be able to “sell”, “share”, and anyway distribute that information. Therefore, Big Data and Internet 2.0 should be considered, also within the context of project management, as resources, part of the “knowledge infrastructure”: and could dramatically affect the way you work. The general concept is: a project “consumes” resources and “uses” knowledge to generate something new- including, through the same mechanism, a continuous stream of information about the project itself.
2.3 A XXI century definition for “project” I already saw across my career one or more of the elements outlined in this section, but only the evolutions outlined under the previous sections actually made it all converge. Timeframe Keyword Temporary Organization Created
(late) XXI century
You decide when and for how long It has a structure and “social” reference Somebody is the project owner
You converge and synchronize It can be also just emerge by interaction, based on the constraints associated with the (financial, human, knowledge) resources It is a negotiation and choice akin to selecting a suit: off-the-rack, with changes, tailored There might be no delivery at all- just a concept, followed by delivery when needed (call it “universal just-intime” with both undefined customers and suppliers)
Somebody has the lead in choosing it
Already Agile changed it, but generally you still have to “see” business products delivered according to an agreed business case
How could it work? You have a need, and launch it as a “scout” on the “knowledge continuum”- even without a budget definition, if you have no idea (an evolution of the old “BoM”, Bill of Materials, in manufacturing). Then, your scout brings back options based on your preferences, and, if confirmed, both procurement and payment are mutually associated.. In such an environment, where every “knowledge element” is structured, certified, and confirmed, it makes no sense to assume that you have to verify it or decide when and if to pay- exchange is the economic act. Moreover, once you see the budget, you could actually finance it by making your future “product” available for others- future delivery.
#QuPlan – A Quantum of Planning
I know that most large customers will say that actually, since at least the 1980s (with a vengeance since the Web was used for business purposes, in mid- to late-1990s), they are actually operating more often than not in the latter mode (how many times you buy something that exists just on paper?). Anyway, this also means that, in the end, Big Data and Internet 2.0 (call it something different) will be a kind of “Hyperuranos”26: resources might be time spent by somebody to do something for you, knowledge/experience that is recycled to fulfill your own purposes, or a mutual exchange that generates new knowledge, experience, and overall cultural artefacts that then assume their own market value, and join the “global resource catalogue”. The interesting part is that projects that are currently not feasible (e.g. I lack the resources and skills to build a piece of furniture) might become instantaneously so, as one of your “scouts” could obviously carry along your own catalogue, and would be able to build a network of exchanges. If this seems too complex, it is only because we are thinking within the box of our current social structure and mores: imagine telling somebody just one hundred years ago that you will not need to have money in your pocket anymore, and that you would have been able by now to talk with everybody everywhere and exchange products, services, payments without having to visit a bank or a shop, or even to know each other. We call that Internet and e-commerce… Anyway, before this wonderful/horrific scenario (depends on your perspective) is in place, you can start doing it within your company- if you start evolving your own “knowledgebase” from just what is “technically available” (software), to what is “culturally available” (e.g. what is implied in adding a new service that interacts with customers, in your own way). This approach could actually convert some of the existing “gatekeeping” offices into mere “knowledgebase feeding and coaching/training units”, as I proposed almost a couple of decades ago to a large customer to convert the marketing and purchase functions.
It is by no chance that I elected that as my location on http://www.facebook.com/robertolofaro, years ago
2.4. Projectify your organization- the app paradigm On a more technical side, some companies already experimented over the last couple of years with the technological equivalent, a “marketplace” for applications (based on smartphones concepts). But, obviously, what is needed is the gradual adoption of a different organizational structure, built around demand instead of offer. If you adopt (at least conceptually) the paradigm discussed in the previous sections, you will probably start thinking that “project” loses most of its traditional “bureaucratic” side. Actually, you can start seeing projects everywhere, as what matters is its non-repeatable nature- everything else is a side-effect of what converges to generate the desired outcomes within the desired timeframe and budget In traditional businesses, the difference between a service and a project can be often explained to non-business people by comparing with cooking. If you create a new recipe, that’s a project. If you read a recipe aiming to cook something for nth time, that’s a service- there might be small variants, but it is still recognizable as an instance of the original recipe. So, if you move away from “ideological” battles about service vs. project management, you can start seeing that, in reality, also most interventions e.g. to evolve or improve a service, or variants add-on on a service composed as a one-off instance of that service (“event”), are projects. Compress time and resources, add that most variants can be automatically generated by aggregating “knowledge snippets”27, and you will get a different model, where you can move from paying per-project or perservice to per-use across all the supply chain. If you have a smartphone, or even a Macintosh or Linux computer, you have been used for a long time to add something new by simply looking at a catalogue, and dropping e.g. on your “desktop” a widget that shows a weather forecast for your location. 27
http://www.tinyurl.com/bfm2013, chapter 2 «Improving the use and control»
#QuPlan – A Quantum of Planning
The point is: you do not need to be a technical expert: you just have to be told which simple, straightforward, (business) intuitive service is provided by that specific app- and drag-and-drop it to activate it on your computer or smartphone or tablet. With the increase in speed and power of both devices and networks, and the expanded availability of information about everything, any use can actually become an additional “configuration” whose set-up can be shared and sold. Yes, also “copyright”, “IPR”, and “patentable process” might evolve, and turn into part of the social and technical infrastructure. Example: if you combine specific appliances in your home, a telepresence unit connecting to your office for teleworking, and a computer with a database and a centralized system, setting up that configuration and tuning it costs time, effort, and often more than a little bit of “try&tune”. Imagine if all the traffic associated to that configuration activity (your “project”) and its final state (your “deliverables”) were to become part of the “global service catalogue”, so that, in a future “Hypergoogle” you could just pick-and-choose your current status, write your aims, and have a solution already expensively developed and applied by others automatically proposed as a configuration to solve your problems (call it a smarter “semantic web”28). In this case, a previous project is turned into a service- and what matters is, obviously, pricing and negotiation. At least, this would allow a geometric progression of the number of “solutions delivered”, i.e. the more solutions are shared, the faster new ones will be generated, while offsetting most of the investment by its reuses. Obviously, this is one case in which I would prefer to have a “compliance framework” in place before it starts- as, once started, it is difficult to pull it back or fix it also for what is already in place. It is commonly described as “once it is online, it stays online”29. 28
http://www.tinyurl.com/bsn2013, chapter 4 «why and how – signposts»
The first casualty of such a system is, obviously, your run-of-the-mill system integrator and ICT department: what is the use for them, if not as “scouts” to look for what other did, and maybe “initiators” for new ideas? Now, extend the paradigm, and think about building a “catalogue” of what is available and can be re-used in your organization without any need to spend endless time and resources “tweaking” it: probably next to nothing. The first point is that anything that can be used to start introducing the ability for others to integrate in their projects what you already have requires altering the way you define, initiate, and deliver a project. It is akin to ISO9000 quality in the 1990s: if it is just an add-on, either it doesn’t work, or it is an overhead. If you start embedding in your design and delivery processes quality requirements, then, along with the obvious benefits in terms of quality perceived by customers, your compliance with ISO9000 does not require any additional effort. What is an app? It is something that you know in terms of both what it delivers, and that you can assume that can work with other apps on the same “environment” (smartphone, computer, tablet, whatever other device will accept apps in the future). Therefore, an app is defined both by what it delivers, and by how it uses the interfaces available (e.g. some apps on your smartphone “need” to read you contacts list, others don’t)- but has also some constraints, defined by the environment (e.g. a specific version of Android or iOS allows). The “business products” delivered by most projects are still designed as a free-standing object with add-on interfaces to the rest of the environment, moreover when the design and delivery are done by a supplier that doesn’t know your own way of doing things. In ICT as well as in areas from organizational design to physical product development, I have always strived, when the deliverable had to be left as an “open box” (something that then the customer has to evolve, not just use or “fix the interfaces”), to provide something more- to provide something that could be part and parcel of the local “business culture”.
#QuPlan – A Quantum of Planning
The first step to adopt the app paradigm is to define your own approach- in the simplest way possible. Then, you have to consider converting your own professional project managers into coaches and advisors for others, and scale down the bureaucratic requirements. Finally, projects should be identified, proposed, started from the bottom, not from the top: guidelines are provided from the top (replacing the old “strategic planning”), but then you have to involve most of the organizational structure to be able to deliver, within those guidelines (I hate the terms “vision”, “mission”- it has to be of more practical use), proposals for new projects, whose feasibility is peer-reviewed. Obviously, it will take a while, as the first step is really the one that is followed by both “pilot” activities. Somebody would call them “brainwashing”: a customer told me decades ago that I had converted his project managers into a sect who in meetings started referring to what I had said or how I would have done something. If you talk with founders of start-ups working on the development of apps, they are obsessed on what they want to deliver, but take for granted the “underlying app culture” and business ecosystem. There are some who develop apps just for their own self-gratification, but those that see that as their own business usually follow a different path. It is common knowledge that few start-ups or companies made money by developing apps- and that is what it is supposed to be. As I wrote above, if you “projectify” your company by adopting the app paradigm, you have also to consider that there are few basic realities that cannot be avoided: no matter how good you believe that your app is, it either has to fulfill an existing need, or initiate the need (create a market). Obviously, the latter is an expensive proposition: acting as an “evangelist” is fine if you have a corporation behind you, not if you are starting a new business- “converting the masses” is an expensive proposition.
2.5. Corporate planning and swarming In few decades, the approach that I outlined in the previous sections will be commonplace in most industries, moreover if, as I discussed recently with an online friend, repetitive activities with low levels of unpredictable intellectual content will be automated- from robots to telepresence+ (i.e. a device that actually does something, not just represent you at a different location- I posted online articles on the evolution of telepresence in the past30). There isn’t really anymore (if there ever was) a dichotomy between “leaders” and “followers”; in business: you can be both, at different times or in different cases and domains, and striving to be either all time could be, again, an expensive proposition that misallocates resources. A cultural change within a company requires time- more so, when you are trying not just to replicate and adapt/adopt “best practices”, but to create new best practices, or follow those that nobody yet has proved to be successful. In sections 2.1. and 2.4. I hinted also at changes required within the concept of corporate planning, something that has already partially been done in manufacturing companies following Lean/Six Sigma and Just-intime not just in production, but also in design and on administration. You cannot assume to have universal knowledge, and often your suppliers or customers are those who can help you to design products that are more able to fulfill not just the current needs of your market, but even to open a new market, or needs that are currently “filtered” by your design. In the future, access to continuous data about the use of your products and services will be commonplace, and what I considered plain vanilla in cultural and organizational change since 1990 (i.e. to monitor what happens so that you can continuously learn and identify potential training or product or service needs) can, again, become part of the “market monitoring” function (e.g. look at recent cars and their data-intensive features). I hinted previously at replacing traditional corporate planning with something that is altogether different from “vision”, “mission”, and all that 1990s (but still lingering on) concepts. 30
#QuPlan – A Quantum of Planning
Bringing into your organization an app paradigm implies not just that projects aren’t anymore a bureaucratic nightmare, but also that you have to expand the delegation of operational power. Swarming is often misunderstood as a kind of anarchy that magically converges on a shared objective. But if you get back to the source, you see that there are few elements in common with the app orientation: if you have a swarm, communication within it doesn’t need to be sophisticated, as each member of the swarm can make assumptions on what other members of the swarm are able to do. Many human applications of swarm-attitude (e.g. on social networks) are really hierarchical structures were most of the swarm is manipulated by few into steering in a specific “direction”. We adopted the name from nature, but probably the closest to a real implementation of the swarm concept is within new robotic/drone minidevices, able to move in group without that much of communication. Probably, a simple example of a future corporate use of a swarm attitude would make the concept clearer. Let’ say that your organization is a bank- and that there is a new competitor unexpectedly coming from a different industry (let’s ignore that probably signals were already there). I will ignore the old method of reacting to such a threat- and instead focus on the new one. Before there is even a hint of an announce, somebody in your organization will start noticing e.g. job announces for positions referring to banking but not in banking. At the same time, preparing a new banking activity for a non-banking company implies preparing plenty of other activities: and those too might be seen by somebody in your organization. If you have no app orientation, where each bit of knowledge contributes to the overall aggregate, all those signals might be lost.
If you have a “collection”/”knowledge marketplace” mechanism, all those signals turn into a pattern, and a pattern might suggest to some within your organization to spending some time on it. To make a long story short: “micro exploratory/monitoring projects” might start as parallel activities, but eventually turn into something that delivers up visible signs of a potential threat, along with potential responses, as, using the same mechanism, independent quests will build a feed-back cycle within the same “knowledge marketplace”, and eventually aggregate in one project- a snowball effect. The same applies for potential changes- or potential new ventures. Obviously, there are still guidelines, and there is still prioritization (associated with the guidelines) at the top (to avoid people wasting time and resources by converting their own personal curiosity into a “business need”)- but in this way the potential aggregate knowledge and “signal collection” of all the organization is not wasted through red tape. It is just one step further from the now traditional “collecting suggestions from those on the field”- it is an organization managed by “emergence”. It might even make sense for a corporation, in this case, to pay its employees free access to media through electronic channels, or subscriptions to magazines of their own choice, in exchange for the Big Data on use of such information sources (as most of those “signals” will be collected involuntarily). Why? Because if, say, A is an employee working as a Sales Controller, probably there will be some “business patterns” that will filter in her/his readings, and if you see that focus to converge in others, that might help your company to identify what could be of potential interest to others, and infer decisions that are made- it could actually makes sense to have incentives for employees to attend events with their peer, to stimulate the creation of a shared lingo and the associated shared behavioral traits, whose patterns you can then feed into your “monitoring system”. Back to the banking example: so, when the competitor announces a new service… you will probably have something to offer (maybe even better, leveraging on your own banking expertise).
#QuPlan – A Quantum of Planning
I selected as an example the banking industry because it is obviously one of the those that theoretically manages only “virtual objects”, but is both expanding and under attack from any organization that uses or generates massive financial flows. If your services or product are commodities, why should not others provide them, maybe leveraging on their own specific expertise in their own field to introduce processes new to your industry, but old, true-and-tried in their own? Already Mintzberg31 was criticizing the concept of corporate planning in the 1990s, but it is still widespread, and, in my experience, most of the signals are collected at the bottom of the corporate pyramid, but reach the top too late to be useful as a competitive advantage. Actually: in most cases, only messages reinforcing corporate decisions are filtered up, delaying the collection of signals that, e.g. a forecast is offthe-mark, also if those on the ground know that fairly well in advance. “Thinking outside the box” is usually seen as delivering value on a specific activity or set of activities- but not as an overall paradigm to adoptalso because, at the top as well as in specialized business functions, it pays to be focused- and this creates a tunnel vision32. It is relatively easy to extend this system to suppliers and key customers in your own “supply chain”, as it was done in the past e.g. for Electronic Data Interchange, Just-in-Time, or even by states that increasingly delegated to corporations the pre-processing of data that they used to aggregate (from risk in banking, to data about payroll, retirement benefits, or even foodprocessing supply chain “traceability”); a similar case study is used for the online component of this book33. But, as any corporate culture change, it is advisable to start small within your own organization, and then build on success: a long journey begins with the first step. 31
Mintzberg “The rise and fall of strategic planning”, 1994, Prentice Hall, ISBN 0137818246 32
And, incidentally, it is a change that could benefit from external advisors, but from day one it must be considered a critical business activity that will be steered by people who have a clear and public mandate from the top, to deliver something that can be evolved using internal resources. You visit the surgeon to have something fixed, but then it is up to you to steer through your recovery- you don’t hire the surgeon on your staff. For the time being- enjoy your journey.
APPENDIX A. SOFTWARE CLASSES COMPARISON
While preparing this book, the first step was obviously to define a business case that would enable to show how each one of the options available would “shine” under different characteristic: despite what software vendors say, I proved by working across probably a dozen of different combinations (or more) that there is no “perfect solution”. In this case, my aim was to identify rough “classes” of solutions that could be used for project management, and not to suggest a Frankenstein of project management. Therefore, I identified, in my experience, four broad classes that could make sense today, whose key characteristics are outlined in the next page: Obviously, you might have other frameworks of reference in mind. Consider the options available and the possibility of portfolios, programmes, projects whose team members are scattered around the globe, and, in a pure “just-in-time” approach, might even be activated “on demand” for short “burst delivery phases” (the next evolution of Agile methodologies, I think). Before reading the page outlining the key characteristics of the three software packages that I selected for this comparison, please read twice the next page, and then try to recollect few projects, while keeping in front of you a copy of your corporate organizational chart.
It makes sense to consider the four classes outlined as “Lego™ bricks”, that you can use to define your own information and service architecture while setting up your way to manage and support projects. Coordination offices are probably on their way out in our future organizational charts (at least in some industries), as, once you have defined the boundaries of your activities, it makes probably sense to focus on “ad hoc organizational structures within a shared corporate culture”. As with the “next evolution of Agile” that I referred to above, this is actually already being experimented since decades in both industry and military operations: why should corporate environments still look as if they were armies organized according to XVIII century rules? Do not get carried away by “trendy” lingo, be it the Agile of today (its rugby-derived Scrum is notably creative on the lingo side), with the associated paraphernalia (certifications, barriers to entry into the industry) that any new methodology or “standardization drive” generates. Focus instead on assembling the best resources available with the minimal overhead possible, and ensuring that they deliver what you need, not just fancy presentations explaining why they weren’t able to deliver. Most software tools have way too many options available: in some cases, I would frankly suggest to stick to the “Office productivity” option for a while, until you have defined what you need.
#QuPlan – A Quantum of Planning
A.1. Microsoft Project 2010 and 2013: “the” planning tool Obviously, choosing to add in this comparison Microsoft Project was a no-brainer: many companies complain about its licensing costs, but, frankly, it is worth its price (if you just need a Gantt, look at A.2.). Its integration with the Server version, Sharepoint, and Visio adds further features, but probably those are an overkill in many organizationsand a risk, if you haven’t defined before how those tools should be used, and who should update what where, as you will risk information to be “logically” scattered all over the place. A.2. Project-in-a-box 2.2.2.003/Planner 3.3: a workflow approach I discovered Project-in-a-box (PIAB henceforth) by chance, while I was looking for a project management tool that supported MSP, the programme management methodology originally released by UK’s OGC. PIAB has an approach that is quite distinctive, as the “planner” covers basic planning and scheduling needs (as well as risks), but the true strength of PIAB is that it is based on methodology workflows (e.g. for PRINCE2, ITIL, others- including the ability to create your own). A.3. DotProject: a web-based planning and collaboration platform This OpenSource tool was actually the inspiration for many of those “online project management” websites available now, and it is both extendable and free; its main strength is that it allows to associate forums with projects, so that you can add and remove resources and have all of them aligned without shuttling around email messages. I used it for both projects and to manage a pipeline of concurrent projects and start-ups, and you can actually use the platform to integrate both a CRM role, while it is so easy to adapt and expand that others released modules e.g. to generate automatically invoicing for the activities carried out within a project, and you can manage a portfolio of projects of services for each customer, with as complex a distribution of roles as you can think. A nice element: it contains also a “logging”, along with forums that can be associated to projects and companies- useful for compliance purposes within your PMO (from ISO9000 to SOX)- and it is free.
APPENDIX B. THE ONLINE COMPONENT
I had planned to release first the book, then the online component. Obviously, I had in mind what I wanted to write about- but after completing the first part of this book, I acknowledged that it would be much more useful and interesting if I were able to release both the book and the additional material online more or less at the same time. You can find the online material on my books website34. My books are mainly knowledge-sharing in preparation of a new service, and therefore I do not expect them to produce a revenue stream large enough to justify procuring funding to support that as a service, also if obviously that can change in the future- hence, it is a free platform. Therefore, consider, for the time being, any online component as a simpler way to reduce the costs of publishing a book, and share material that you can immediately re-use or share with others. Obviously, you can contact me on Linkedin to suggest changes and share your feed-back.
B.1. What you will find online
Look at the picture above as your “map” through the online content. Tracking information while keeping a consistent and up-to-date document repository (be it for just one project or a whole portfolio or programme) is more a matter of method than fancy software tools. As for the decision guidelines: they are obviously a work-in-progress and highly dependent on the constraints available in your own environment (as an example, few would build a skyscraper with a “develop as you go” plan for the foundations). The next two sections briefly describe the first two elements, “Process” and “Outlined examples”, while decision guidelines will be released online once in a while, using a “questionnaire” format.
#QuPlan – A Quantum of Planning
In order to avoid entering into a definitional battlefield by exposing the “lingo” of a specific methodology, I outlined above the process that I usually follow. Be it an environment using PRINCE/2, PMI/PMBoK, something else, or a custom methodology to manage projects, and Waterfall or any flavor of Agile to produce the results expected by the project, in my experience in corporate environments since the 1980s you have to at least: define the boundaries of your engagement (call it “scope”) start officially the project (and communicate about it) have one or more iterations of “execute”, “assess”, “close”, “transition” (the latter being called as “release in production”) eventually do something that few projects really do: talk frankly with your customer, to transfer not just the knowledge about what your deliver (be it a building, a computer software, or just a feasibility study), but also a kind of “Captain’s log” on what happened, why, the decision taken (positive and negative), and anything else that could be useful to know should either you or your customers be called in the future to work together, or work on something similar. Obviously, I advocate clearly announcing that there will be this phase if not while negotiating the project budget, at least on or before the kickstart. Actually, this activity is even more important if the organization where the project is delivered has no formal Project Support, Portfolio, Programme, Project Management, or other methodological support (including a knowledge management or quality function).
B.3. Outlined examples
The first step was obviously to define a business case that would enable to show how each one of the options available would “shine” under different characteristic: despite what software vendors say, I proved by working across probably a dozen of different combinations (or more) that there is no “perfect solution”. In this case, the business case had to cover both the programme level and non-ICT activities, and therefore, after creating the business case, and documenting it through a draft plan that helped to better define the “boundaries” (the “vision”, if you prefer), I started splitting the macro-areas of intervention into a series of subprojects, divided roughly by discipline, time of resources involved, and constraints. Then, I selected a specific subproject to further detail, a kind of “fact finding” before carrying out the activities, to be used also to better focus the ensuing activities. Finally, all this information was finally applied using the four architectures described above. You will find online the Gantt chart and a discussion on how each product compares with the “Office&Files” solution35 35
The printed version is on Amazon- see https://robertolofaro.com/ctd02 (introduction to the series: see https://robertolofaro.com/ctd). Plan...
Published on Mar 23, 2015
The printed version is on Amazon- see https://robertolofaro.com/ctd02 (introduction to the series: see https://robertolofaro.com/ctd). Plan...