Today we’re privileged be with Karen Favazza Spencer, author of the Agile primer A to XP: The Agile ABC Book (ISBN: 978-0-9883358-0-6), available at Agile Kindergarten. Karen’s book is not only used here in North America (where I sit), but also Europe, India, and Australia.
Good afternoon, Karen. What, in your view, is “Agile”?
A: Hi Dave. Agile is the marriage of scientific empiricism and social psychology. It is an umbrella term for several project and product management frameworks. Agile works well when the work to be done is complex and the methods necessary to accomplish the work are not yet fully understood.
Agile “chunks” functionality so that small bits of business value are delivered to the customer on a schedule; typically a one-to-four week schedule. This schedule provides the customer and technical team with ready opportunity to validate the product, and incorporate change, based on timely feedback, as well as experience. This process allows the business to better forecast the time required to complete complex features based on their ongoing experience.
Shared ownership, transparency and small cross-functional teams are a few of the cultural underpinnings of the Agile frameworks, such as Scrum, Lean and eXtreme Programming. Consequently, knowing how to collaboratively make decisions, and how to deal with interpersonal conflict constructively, are foundational skills in an Agile shop.
What inspired you to write this book?
A: Well, when talking with different teams, both co-located and distributed, in different companies, I asked “What books have you read on Agile?” A dozen or more team members all gave me the same answer: “None.” When asked why, they justified this with “I’ve got one on the shelf but haven’t gotten around to reading it yet,” or, “we don’t have to read about Agile because we’re doing it,” or, “I don’t know which one to read, there are so many.” I decided that what was needed was an obvious entry point – something engaging and easy to use.
I see; then what is your book’s main argument?
A: A to XP is basically a job aid. Like any ABC book, it’s an introduction to literacy. What I’ve done is arranged about 100 Agile concepts around 26 themes, so that things hang together. For example, I talk about pairing and swarming behaviors in context with Continuous improvement and Emergent Design, all under the theme of Planning, accompanied by an illustration that shows the iterative nature of the framework.
A: Everyone using or interested in using Agile practices. Agilists such as Scrum Masters, Product Owners, Coaches or Teams, Business stakeholders, and C-level or other management.
What is unique and original about your book, and your thinking?
A: That’s the question! It is unique. It would have been easier to write 10 pages on each of the 26 themes, which would have resulted in a traditional book. But I wanted something that could be read in 30 minutes, and skimmed in 5. I wanted something that could serve as a quick and handy “cheat-sheet.” I wanted each of the themes to be absorbable at a glance. So I decided to use three methods of communication – 1) a simple illustration of the concept, 2) a heading like a proverb that was pithy and memorable, and 3) a rational paragraph or two that would provide more substance. What I tried to do was to access the metaphorical mind – our right brain, or narrative mind as Steve Denning calls it. I pair this with branded formatting: Unique illustrations, memorable hooks, and the rational argument to support each concept. In this way, readers actually LEARN the concept. In other words, I wanted to walk the Agile talk by providing just enough information, in easy to understand chunks, so that the concepts on each page would be DONE when you turned the page.
How specifically can your book help an organization; an individual?
A: Having a common glossary of terms, or shared understanding of concepts, is central to smooth operations. We all think we think the same, but often discover we don’t – at inopportune times. The Agile ABC Book gives everyone a common-understanding from which to start. What’s more, the How to Use this Book section provides a workshop format for teams to practice Agile meetings, where they can further explore their mutual interpretation of any one of the 100 concepts. This guides them toward creating their own Action Plan for improvement.
A: Management might be interested in the cultural implications of doing work in an Agile way, yet may not really understand what stresses it will bring to bear on their typical operational structure. The themes Why, Team, Quality and Greatness all speak to that cultural mindshift. Other themes such as Whiteboards, Scrum and Information Radiators communicate more behavioral information.
What happens in some Agile adoptions is that very superficial and often modified, or incomplete, frameworks are put in place, that subsequently fail to deliver on the Agile promise of high productivity. Agile simply doesn’t work if you pick and choose. It would be as if you chose which bits to use when assembling a piece of furniture; it might end up looking good, but functionally it would be unsound. It pains many Agile coaches and Agile consultants when the enterprise sets itself up for difficulties with this à la carte mentality. I provide a cohesive model of proper Agile that outlines the transformation agenda – a balanced diet, so-to-speak.
What does following your book’s principles mean beyond IT – that is; to business and related successes?
A: Glad you ask that, Dave, because although Agile in general, and Scrum & XP in particular, are closely associated with IT, Agile also speaks to the business mind. A CFO or a business manager can use A to XP as a primer in preparation for conversations with the technical folks.
One of the reasons the short proverbs and images work so well with the Agile concepts is that all of us, business people and engineers alike, have a basic understanding of these principles from life experience. Let’s face it; people tend to overcomplicate things. Granted, the technology we are using and the products we want to create can be complicated, but execution should be incremental, output should be cohesive and business value should be clear. Everything has to fit together in a way that is flexible and sustainable. Agile provides a conceptual language that does that.
What Agile is about at its core is GOOD DECISION MAKING PRACTICES – and my book speaks to this. It’s about seeing the forest and the trees… the greater picture, the long-range implications, along with the pragmatic step-by-step work that needs to be done. It’s about aligning strategy with tactics… but it’s about more… it’s about Value Driven Leadership and Respect for the Individual.
Well thank you Karen, for “being” here with us today – is there a nice summary you’d like to wrap with?
A: I’d like to say that if you’d like a “Cliff Notes” version of Agile, if you want something that you can actually use, even on-the-fly, to spark meaningful conversations with your colleagues, if you need help in your Agile Adoption or Agile Transformation so that you make better collaborative decisions, then get multiple copies of A to XP and use them to develop your, and your organization’s, literacy. This is a book that is meant to be used.
Thank you Karen: Today’s guest has been Karen Spencer, author of A to XP: The Agile ABC Book (ISBN: 978-0-9883358-0-6) available at Agile Kindergarten.
Well… I’ve frequently spoken about a new agility being necessary for organizations, and their subsequent ability to mount new security initiatives quickly, in response to fast-changing threats. Happily, tomorrow, I’ll have an interview with the author of the book, “A to XP: The Agile ABC Book.” Agile, as a discipline and a business process management practice, serves the threat landscape well: It applies where the unpredictable is common; and where business processes cannot change quickly enough for necessary business practices.
But that’s tomorrow – back to mainstream awareness: There’s a growing unease amongst the general populace regarding cyber attack, cyber terror, cyber war… and just hacks in general… a burgeoning awareness. There can perhaps be no better indicator of any particular thing’s ubiquitous nature than its inclusion to Late Night television fare.
The other evening, on “Late Night with Jimmy Fallon” (NBC), Fallon mounted a joke that shows just how mainstream cyber awareness has become:
“This is scary – a new report shows that Chinese hackers could one day take out America’s power supply. Or as that’s also known: Pulling a ‘Beyonce.’”
This is an obvious reference to the recent power outage at the Super Bowl, and speculation that Beyonce’s half-time show taxed the stadium’s or region’s power capabilities, perhaps overloading equipment… or something like that. (Whatever was the cause, they obviously need new, comprehensive, backup plans and systems).
But the awareness grows: It’s now in the comic; economic; personal; and military realms: General Jack Keane, former Vice Chief of Staff of the U.S. Army, and now a Fox News military analyst, states that the U.S. is “the best” when it comes to things such as hacking, cyber espionage, and related activities; that Russia is second; and that China is third. However, according to him, China is “by far the most prolific,” stating that thousands of the People’s Liberation Army (PLA) members engage in cyber hacking daily, further assisted by civilian hackers and contractors – penetrating thousands of U.S. companies.
They have penetrated political, economic, and military intelligence realms, stealing related intellectual property – thus stealing technology and innovation to use in advancing their own economic interests.
At the same time, another far more local challenge exists: Retail Cyber Attacks. Retailers are targets of 45% of all computer hacker attacks in 2012. There are an estimated 79 successful cyber attacks a week on U.S. businesses.
36% of all targeted cyber attacks in the U.S. are aimed at small businesses. Those are the very ones that cannot afford robust, up-to-the-minute, protections. They also can’t afford to be without them. A dichotomy.
Hand-in-hand with hacking go the flourishing underground industries that bundle together customer information; addresses; credit card numbers; PINs, and such, and utilize them – or sell them to other crime syndicates.
Consider: A Subway breach had a compromise of data involving 80,000 customers: Unauthorized transactions were made for 3 years on that data.
So we find that what’s turning out to be an omnipresent awareness for cyber vulnerabilities must be paired with a new agility: Tomorrow, Ms. Karen Spencer will share with us her thoughts on Agile, as contained in her book.
Further, a tweet indicated that “the whopper flopped” and that BK had thus been sold to McDonald’s. Several other tweets contained obscenities.
It’s not clear who hacked BK’s account, and I am not implying that it was a “competitor hack” (that is, it was not likely initiated by McDonald’s, or any potential rogue employee of that firm – although the Hamburglar’s criminal tendencies are well-established).
However, this hack has to fit squarely into one of two realms, and it provides a nice entrée to some new definitions for an evolving threat landscape. Let’s create the concept of a “branded hack” that is unique to this forum – branded hacks that will be handles for discussion, and which will hopefully propagate for ease-of-discussion at orgs, with vendors, with media, etc.: 1) Competitor-Hack (CH), and 2) Hack-at-Random (HaR). This is a good opportunity to define these two types of hacks, for purpose of establishing exactly “where we are” in 2013, in getting to where we need to go – these definitions will likely evolve a bit:
New Definitions for New Realities
Competitor-Hack (CH): This is a directed hack by a business competitor, with a business motivation: The purpose of disrupting the competition’s ability to conduct competing business through harm to enablements (data, infrastructure, apps, etc.), or to cause damage to any specific competitor’s reputation (such as false Tweets, implanting of false content, false business positions, etc.). These CHs can include political motivations, and political targets – they include any orgs and/or individuals who compete on some plane.
Hack-at-Random (HaR): This is an attack that has more of a mischievous spirit as motivator. Motivators can include humor, bragging rights, or even the preference of Big Macs over Whoppers, or Whoppers over Big Macs – but generally speaking, the people mounting these are not employees or formal representatives of the organizations in question – they are people who mount trouble for sport and fun.
Recognize this: In discussing cybersecurity a few articles ago, as contained in this post, and as indicated in another post’s matrix, I mentioned that organizations would have to guard against CHs from business competitors. I also debuted the concept of HaR. It is easy enough for me to envision these things coming, as immodest as that may sound: In the realm of risk, unmanaged possibilities become probabilities.
It is easy enough to see that risk is being compounded by three fundamental things that are being driven to everyone:
Ever-more power, affordability, and capability are being driven to very modest “players” and devices.
Ever-more robust hacking tools will be available on rogue “gaming” sites, and the business and sport of hacking is going to explode. Watch for it – and be positioned to guard against it.
In the next 2 to 10 years, the securing of business will take on a whole new dimension from the perspective of “whole view” considerations. In my book, I.T. Wars, I spoke throughout of regional business security teams – BizSec – that would be comprised of business and government representatives. Orgs would partner with outside agencies, local government, and Federal government, in order to plan larger-scale securities to business enabling things, such as infrastructure, the power grid, utilities, etc.
The various BizSecs will have their work cut out for them. Hacks-at-Random (HAR) will become a nuisance at minimum; a business-ender at maximum. Nefarious mischief makers will take down organizations for sport. Those orgs that do not maintain the most forward-edge, vigilant, protections will be victims: That is simply how it will be. Organizations will also openly discuss potential cyber attack from larger forces, for sized and proportioned positionings (We’ll be discussing these, and how to get positioned, in upcoming posts).
Perhaps an early sign of new awarenesses and realities concerning cyber and related securities will be the end of above ground electrical grid considerations. Watch for “telephone poles” to disappear in the coming decade – at least in certain areas, particularly Washington, DC.
Wires and related infrastructure will go into underground, hopefully EMP-proof, conduits.
A corresponding example is potent: After recent hurricanes, there were calls for the burying of electrical lines and cables – when you think about it, above-ground lines, poles and towers seem positively archaic – they’re so “last century.” In fact, above ground infrastructure does date back to the very beginning of the last century – and it is quite plainly woefully out-of-date.
Placing this infrastructure underground removes the liability of damage and disablement from weather; such as hurricanes, or just high winds (any corresponding consideration of risk from earthquakes is offset by the fact that above-ground poles would likely fall anyway – and earthquake damage will simply require cleanup and reconstitution of infrastructure as normally performed).
A comprehensive plan to protect lines through a grid of underground conduits should be a national plan, much like the interstate highway system was.
This project and progression is already being discussed within the Federal government.
NP: Talk is Cheap, Keith Richards, original LP
The other day, in the article Cyberwar: A consideration for business protections?, we asked a few questions vis-à-vis cyberwarfare:
Outside: What are the modern organization’s possible contributions to surrounding outside public enablements and related security there? [Think: electrical grid; communications; infrastructure such as roads, etc.]
Inside: What are your new requirements concerning internal controls and security measures? [Think: Malware comprehensiveness and timeliness; firewalls; education, etc.]
In advancing the discussion, recognize that any modern organization with reliance on electronic enablements, applications, processing, content, and the dynamic flow of information, is vulnerable due to both outside liabilities, and inside liabilities. But further, the organization will face threat with two other distinct characteristics. There will be national threats (originating outside) that impact inside – and there will be local threats, also with corresponding inside impacts. Further, there will be your own inside perils, due to deficiencies, deliberate harm, or human error. We can evolve the following matrix over time for a more comprehensive understanding… and for the taking of appropriate (affordable) action:
Nation-states: The organization is vulnerable to national threats, as delivered by outside nation-states, both formal ones such as China, as well as virtual “nations” of thought or philosophy or action, such as al-Qaeda.
If you believe the “local” organization – that is, yours – is not susceptible to large cyber threats… read on…
It’s been reported recently that the President of the United States could order a pre-emptive cyber strike if a major cyber plot was detected and deemed credible. We’re talking about a cyber plot as mounted against the U.S. by a foreign and hostile country or entity. (In fact, tonight’s (2-12-13) State of the Union address is going to contain mention of cyberwar as a national threat).
This reportage is not in the context of President Obama potentially ordering, or considering, such a strike: Rather, this was a discussion for the legalities of any president, now or future, for ordering such a strike. In other words, a general legal and Constitutional question, and potentials for action. In this regard, The National Intelligence Estimate, considered the intelligence community’s most authoritative document, has been updated and is commissioned to focus on cyber security, with special focus on Iran, North Korea, and China.
Orgs close for inclement weather – will they close for inclement cyber conditions?
So, we’re plowing new ground – and, like it or not, considerations of large-scale cyberwarfare will come to the organization much as considerations of weather do (such as when to close early, when to close entirely, who makes those determinations, etc.) Consider: Will there come a day when a specific national or regional CyberThreat is deemed so high that specific geographic areas are advised to shut down computer systems, in order to take them offline and to remove their vulnerability until the threat is successfully resolved? Computers, critical content, access to apps, and the dynamic flow of information, are necessary to virtually everything we do today: Banking, commerce, travel, education. Technical enablements sustain our power grid; any damage to that cascades to critical areas mentioned in the last few articles here. If national or regional authorities believe some measure of systems supporting the power grid are in a window of vulnerability, might local power “go out” for a period of time? (Much as it does following a bad storm).
So what are the boundaries by which we can execute cyber operations? How “preemptive” are we permitted to be? Former CIA deputy director John McLaughlin says that this is a “new arena, a new frontier, where people can move with stealth, agility, and invisibly.”
The difficult part of “invisibility” is that an enemy can attack, cause great harm, and escape liability or penalty, which in-turn makes it difficult for the attackee to respond, and to mount protection from continued attacks. See how the removal of a MAD scenario exacerbates the threat (one article down, or here).
As to perils to the local organization, we’re already seeing large, private, high-profile targets being hit: The New York Times said Chinese hackers had compromised their computers, stealing employee passwords a few weeks ago. Same for the Washington Post and Wall Street Journal, as they reported similar incidents.
Twitter recently said that 250,000 accounts may have been compromised. A breach at the Department of Energy came to light when employees were notified that servers had been compromised at their headquarters. There have been numerous denial-of-service attacks on U.S. banks.
Large, high-profile, organizations and their associated vulnerabilities are pretty well understood inside of those orgs. But what of small-to-medium business? SMB is particularly vulnerable. But beyond nation-states wreaking large-scale harm, SMB faces both inside and outside threats. Where are their meager resources best-leveraged?
Understanding the problem will advance our discussion in the coming days…
Of course, there’s the nuclear component, and concomitant fear. But hopefully the MAD policy still provides some measure of protection: Mutually Assured Destruction. In MAD, the theory is that if the U.S. or any country and its allies find that their forward-sensing intelligence probes have noted a missile launch, they could then launch their own volley toward the aggressor – each’s missiles traversing and crossing to their respective destinations and –
BOOM! – both countries would lose – so why start?
But things aren’t quite so clear with cyberwarfare. Malware can wreak its destructive vengeance, and then clean up after itself! – hiding its originating trail. Removed is a certain MAD component, opening the way for all sorts of attacks – perhaps… and it’s not just peril from large-scale wars between countries: Let’s not forget or discount another cyberwar possibility: In the future, who’s to say that simple business competitors might not unleash a cyberattack against companies in their market? It is foolish to discount this possibility. It may already have happened.
Let’s also consider a recent event: One minute you’re enjoying a game, the next, half the stadium is dark. Ok, I’m not a conspiracy theorist, but I couldn’t resist a poke at the recent Super Bowl lighting problem. Now that many of us have thought about it, though, it well could have been a (relatively harmless) test-hack performed by a country. For that matter, it could have been a kid in his bedroom. Nah. Still…
Here in America over the past couple decades, the Pentagon and a few intelligence agencies have shared power in deploying cyberweapons. I believe the actual “trigger” for this deployment required Presidential authorization. The highest profile cyber attack was, perhaps, the strike on Iran’s computer systems that run their nuclear enrichment facilities. However, we ain’t seen nothin’ yet as far as cyberwarfare’s actual potential. Potentials of cyberwarfare cannot be ignored – countries not only must safeguard against it; they must envision their use of it (sadly), in staying competitive on the modern, virtual, battlefield – in tandem with the physical one. And, cyberwar’s yield is hardly just virtual: For example, removing any measure of a country’s electrical grid would yield catastrophic “real-world” results –
Imagine: disrupting computers controlling train travel; resultant derailments, to include not only direct crash-related deaths, but the release of toxic chemicals due to crashes. Attacks on water treatment plants, causing illness and death. Crashing of the power grid; homes and businesses without power; rotting food, lack of potable water. Entire industries idle. Disruption of major media, and critical denial of wartime information, and what to do in terms of safety. Removal of power would also inhibit basic 911-type emergency response –prioritizations of emergency activity would revert to “line of sight.” The list can go on and on…
Let this be a call to government and private sector/innovator alike: We need hardening of critical key infrastructure, and the securing of all electronic enablements. We must begin building to “cyberproof” standards… or at least, make the best attempt.
In the coming days, we’ll examine what the emerging responsibilities are for organizations: Your “local” scope of responsibilities and duties is fairly clear, and hopefully covered in your Security, Acceptable Use, and related policies and plans…
So, vis-a-vis cyberwarfare:
Outside: What are the modern organization’s possible contributions to surrounding public enablements and related security there?
Inside: What are your new requirements concerning internal controls and security measures? Stay tuned…
NP: Gerry Mulligan Meets Stan Getz, original LP, Verve, MG V – 8249
A project manager asked a very important question: “How do I communicate with a project stakeholder who thinks they are the project owner?”
She further explained that her organization is replacing a legacy system for which “Stakeholder A” had been the owner. The new, replacement, system is going to serve, in her words, “a much broader community than the legacy system” – which I take to mean: The new system is an enterprise-wide system, serving not only one or a few departments (and an associated limited realm of users/stakeholders), but is now serving a much more comprehensive set of users and stakeholders.
Therefore, the project is owned and now sponsored at a much higher level of the organization – a level higher than Stakeholder A… here’s where a rub comes in:
Stakeholder A sees the project as the next iteration of the legacy system; he or she does not recognize nor acknowledge the reality of the project’s ownership, and true point of power (at the higher level). In the PM’s words, “Stakeholder A is demanding unreasonable input into project team hires, status, etc. Our actual project owner (stakeholder A’s superior) is not willing to bring clarity to the situation.”
Lastly, she asks, “How should I, from a communications perspective, engage with Stakeholder A? How do I preserve a good customer relationship while drawing clear boundaries and setting appropriate expectations?”
Answers on the forum initially counseled getting Stakeholder A and the project owner/sponsor (her words) in a room together, to “lay out the situation for all.” Other counsel was to get the PO (project owner) to “step up – period.” In that last, there is definite peril – the PO outranks the PM. If the PO is not reigning in Stakeholder A, there is a reason that trumps whatever meager power the PM has. Recognize that the PM has some measure of power within and on the project (thought not unlimited), but no real power regarding the PO – other than the power to negotiate (and that negotiation does not include the power to issues fiats, such as “step up – period”).
Other counsel was to refer to the project’s charter (a good idea, but surely the PM likely knows the charter [sanctions, scope, who does what, when, is there a RACI matrix?, etc.]) – and even guidance to “force the issue.” Hmmm… What to do? Here’s a big clue – let’s revisit the original question:
“How do I communicate with a project stakeholder who thinks they are the project owner?”
And let’s work toward answering that original question – before getting multiple people in a room, laying down the law, and attempting to be dogmatic in our expression of who owns the project, who manages the project, and who no longer has leverage, as wielded in the past, by virtue of a system’s graduation to enterprise-wide standing.
First, it’s important to understand where you are (politics, culture, points of power, your sanction, your sponsorship, your power…), in charting a proper course (a travel through milestones, deliverables, and met-expectations), in arriving at the appropriate destination (project’s conclusion, solid delivery; a bona-fide Go-Live that is on time and on target).
It’s not just important to make full understanding for where you are – it’s imperative: Consider this example: Someone calls you from the road; their GPS is out, and they are lost; they need directions to your house. What is your first question? “Where are you right now?”
Where are you indeed: The PM must determine all “Where am I?” type factors before proceeding. This will help the PM determine where he/she is for proper progression, to include how to handle Stakeholder A.
Here, then, is part of where the PM is: Why has the PO not reigned in Stakeholder A? There can be one or more of a couple reasons:
1) The PO has a special relationship with Stakeholder A, and is relying on that person to provide “inside reporting” and opinions on the project’s “true” progress (feeling that this is superior to the project’s formal reporting).
2) Similarly, the PO wants Stakeholder A to exert strong influence on the project. He/She believes that A’s legacy knowledge is beneficial to, perhaps even a requirement for, the enterprise project’s success.
3) The PO fears Stakeholder A for some reason. A formal org chart shows the PO to be a superior, but there is always the “informal” hierarchy of any organization. Further, Stakeholder A may enjoy political favor from a power-person that is superior to the PO.
4) The PO simply doesn’t understand the inefficiency and discomfort that Stakeholder
A can bring/is bringing to the project, by virtue of A’s attempt at wide-ranging influence and power within the larger enterprise-project.
The PM needs to find the circumstances’ fit to any of the above, and perhaps even another possibility, so that the PM knows exactly where he/she is. Then the PM can ascertain that he/she is on the right path for addressing Stakeholder A, before making a mistake that could negatively influence the PM’s career – a mistake that would be completely external to the project at hand, when you think about it.
Ok, the answer to the question? First, meet one-on-one with Stakeholder A. Ascertain what is incentivizing this person. Reincentivize them (see the last few articles in this blog) for a focus that is more “local” in scope – in other words, direct A’s focus to the appropriate piece or pieces of the enterprise puzzle, and away from the whole top-down, wall-to-wall view. Incentivization can involve flattery (but be sincere): “Bob, your input has been great – your knowledge of the system and its history is invaluable. But I need kind of a favor. Can you focus on…? I’m in a bind, and you’re the only person I can really count on for the right quality and efficiency to this part of the project.”
At the same time, remove any feelings of discount that Stakeholder A may be feeling. He/she wants to make project hires? “Bob, I wish I could put your choice for business analyst on the team, but frankly, that choice has been made by the PO.” (Or whomever – the PM can take ownership for the choice if that’s the case; just present the reason for choices). “But, this opens your time up for something I really need help with…” Boost this person’s feeling of contribution, and find appropriate areas and levels for contribution.
So – to sum: Understand Where You Are before trying to craft a route to destination. Incentivize and reincentivize people when necessary. Remove their feelings of discount.
It is possible to become very good at these things. Once you are good at these things, you’ll be amazed at how smooth the most challenging endeavors can be – at least as compared to how things fared prior.
It’s important to recognize that, no matter how wise our PM, the allied team, the business stakeholders, and no matter how effective our project tracking and managing is, we are still vulnerable to certain traps. These traps can rob our efficiency, can imperil milestones and deliveries, and ultimately crash mutually dependent projects and go-lives. Recognizing common traps can help us to side-step them by managing to standards of avoidance. We’ll list some here, but you should also keep your own running list – you’ll develop a recognition of traps that may be specific to your organization’s nature and circumstances.
Not tracking dependencies: Be very aware of the competition for resources. Note all dependencies between projects, such as competition for resources. Document all assumptions. Example: Project A’s Deliverable XYZ is dependent on [Project B’s Deliverable QRS] … [HR’s production of Report LMN] … and so forth.
Over-allocation of Resources/Over-commitment: Again, negotiate all things. Be wary of stretching people too far. Make allowance in budgets for the unforeseen. Further, do not count on resources’ availabilities based on the fact that they’re not committed 100% of the time in any specific place. You don’t want to find out the hard way that a once-a-week utilization for something coincides with the very window you need that critical resource. Or, that something that is used 10% of the time has suddenly gone into a 100% contingency utilization (perhaps due to failure of other resources elsewhere).
Interlocking milestones: Be careful about milestones within one project that are dependent on deliverables from another – goes hand-in-hand with dependencies, above.
The shifting of critical resources to “higher priority” projects: “Higher priorites” is in quotes because these are projects outside of your PM’ing, and therefore the pop-up priorities are normally unknown within your specific plan(s). This one is especially dangerous. Higher powers, above the PM, can strip anything from “your” project or projects – including personnel. When documenting projects at the outset, negotiate with these higher powers – attempt to preserve your understanding and protection of projects’ definitions at the outset. But also, simply ask “What happens if I lose this resource? Is there any chance, no matter how small, of this happening?” If you’re aware of parallel projects that are outside of your purview, that may compete for critical resources, again ask: “What are the perils for this happening? Will there be an understanding that the project(s) under my control can be impacted? I don’t want my team taking responsibility for lags that are not under our direct control.” Define, negotiate, document.
Unrealistic deadlines/deliveries: Again, negotiate with business stakeholders at the outset. Stakeholders must negotiate with IT and the PM. Guard against constant updating and re-baselining of project plans and documentation sets. That defeats the purpose of project management, and is an indication of poor project definition and planning at the outset of projects.
Conflicting priorities: Watch for this carefully. Departments and stakeholders may make commitments that they cannot keep. A ripe area to watch for, is where a project may impact profitability. For example: If a key project deliverable falls in a window requiring a temporary shut-down of a production-area during a “busy season,” and that season is a “money-in” winner, you’re likely in a competition you can’t win. Avoid these sorts of conflicts at the outset by being aware of them. Don’t fall into this sort of trap – you can’t afford to impact the organization’s “win” situations with any particular project’s. Examples of your specific liabilities here should readily come to you – avoid conflicting priorities.
Conflicting incentives: As related to priorities, be wary of conflicting incentives, to include organizational loyalties. Not to be overly political, but be aware of relationships between powerful people, departments, and even subordinate players. Folks, particularly in large enterprises, have their points of power and “understandings” – in a pinch, people are going to pitch their efforts to other people, departments, and endeavors that are going to provide them payoffs and future loyalties – that incentivization – and these don’t necessarily track with any particular project’s best interests. Also watch for such things as formal incentives, such as to sales and marketing teams, and levels of efforts in service to that sort of incentivization at the expense of the concurrent project. This obviously stripes into scheduling and prudent project planning – again, avoid these traps.
In avoiding traps, make full exposure of each project’s strengths, inter-dependencies, intra-dependencies, any liabilities, any limits, and build in breathing room for contingencies… even emergencies. It’s always a good idea to identify “backup players” in the event of critical teammembers’ absences. Document assumptions that are employed in creating and sustaining the critical path.
I frequently hear from people who manage projects on a near continuous basis. One project wraps, and another starts almost immediately. I’m not speaking of professional project managers (PMs) here, but of the rest of the usual cast of characters: IT directors, managers, and any collateral people who have the good fortune, or bad misfortune, to be assigned any particular project, be they programmers, business analysts, engineers, support personnel, etc.
PM’ing is a special talent – and that talent’s harbor is not the exclusive domain of PMs, or even people who have various degrees of formalized training in PM’ing. Oftentimes there are folks who just naturally become effective PMs, while many other folks with advanced training just aren’t much good at it. It’s a special talent: One that involves not only technical and business knowledge, but an awareness of politics, an ability to get along with and get the most from a diverse group of people, and a unique ability to adjust to changing project impacts, even as you balance that against adherence to timelines, milestones, budgets, and go-lives. Beyond mere intelligence and knowledge, a good PM is wise. Wisdom is born of native intelligence, experience, and knowledge as applied in a mature and leveraged fashion to any particular endeavor.
And what of the PM who has the task of managing and coordinating multiple projects? Take any challenging element you can think of involving a project, and consider the steroidal impact of that element as it stripes through multiple, concurrent, and even overlapping – mutually reinforcing – projects. Here, there is no “affordability” for mediocre PM,ing, or PMs. We need advanced wisdom. Effectively managing multiple projects requires:
The right team: The PM will pick the right people for various teams; those with the appropriate knowledge and experience. Too, they will be people who can get along with others in difficult circumstances. Projects are a crucible for stress. These people will likely be on multiple teams in large enterprise environments, making their maturity and balance all the more imperative. Pick a mature person who needs a little “spec’ing up” over a less mature person, albeit one with a little more familiarity for the project at-hand, for better long term results. (You may wish to consider establishment of a permanent Business Implementation Team [BIT] that can be activated and inactivated according to organizational demands – people of special knowledge and experience – the team can flex membership too, based on exigencies and requirements. More info can be had here, in the chapter “Getting There: Qualifying the organization for change”).
Resources: Resource allocation is crucial to supporting the critical path of the project’s progression; it’s tracking, timeliness, and support to interim milestone deliveries and ultimate go-live date. Speaking of people, they’re resources too, so be mindful of stretching them too far – maintain a balanced approach on their time, focus, and whatever else they need to be doing outside of the project (if applicable). In addition, be aware of budgets, particularly those that are vulnerable to several projects’ influence. Outside solutions partners, and their time, must be carefully managed too. All resources have limitations – they’re not infinite: Be aware of equipment limitations and balance, to include servers, storage, bandwidth considerations, as well as any facilities that must harbor project elements and activities. Coordinate demands on these items by tracking and balancing multiple projects within all considerations.
Dependencies: Some of our considered dependencies involve that balance of resources we just spoke about. But in addition, understand that one project’s milestone may have another project’s interim deliverable as a dependency. Missing any particular milestone on one project may cause a sequential crashing of other projects’ milestones and deliverables in-turn – sort of like the fall of a string of dominos. Again, managing multiple, within the limits of common resources, is tricky business and requires accurate measurements, tracking, and adjustments.
Milestones: Be certain to establish practical milestones, within all limitations and contingencies (we’ll speak of contingencies in a moment). In this regard, negotiation at projects’ outsets with business stakeholds is imperative. Establish and keep a balanced schedule. In ensuring favorability for meeting milestones, be certain to track performance: people meeting goals; the performance of budget unwinds vs. results; the projects’ adherence to timelines, and so forth. As a PM, or as any support player, don’t allow yourself to get locked into impossible circumstances and deliveries. Negotiate, expose limits and variables, negotiate, weigh, assess, and did I say… negotiate? The PM will be be negotiating not only with business stakeholders, but with his/her project support teammembers.
Contingencies: What happens if a critical member gets sick and is suddenly unavailable to the project? What happens if a resource is pulled, due to an emergency elsewhere? What happens if a go-live is slipped back? Is any particular one of those a deal-breaker on other projects’ deliveries? If so, what happens? Which milestones can adjust back, or forward, in supporting overall commitments? Which milestones must be steadfast, thereby taking priority over other parallel milestones on other projects? Identify and define everything in detail. Make allowance where possible for contingencies, so as to have built-in triggers for prudent adjustments.
In doing all of this, define all things in detail: Required personnel, their level of involvement, interdependencies, and all critical elements. Be certain to set up the tracking for progress and the meeting of interim goals – milestones. Whether formal PM software, or something of your own, ensure it tracks across multiple projects where there are intertwined resources and dependencies. Be certain to understand tracking programs so that you input everything, and everything correctly, in making effective multiple management.
Next up we’ll look at Traps to watch for, that can effect multiple projects (and for that matter, stand-alone projects too).
First: Symantec is monitoring and addressing the threat landscape with a division called STAR: Security, Technology and Response. The team is made up of virus hunters, threat analysts, engineers and researchers. That’s a robust team, and this aggressive forward edge is always necessary, in my opinion. But STAR’s existence owes itself, in part, to a relatively recent and growing recognition:
Today everyone, from consumer to service provider to product developer, is recognizing that the average person has multiple “end points” for data and sensitive information.
For example: Gone is the day of a household, or any house member, with a single, simple device: a desktop PC, for example. Rather, today’s individual may have many multiple devices: smartphones, laptops, iPads, iPods, tablets, portable media players, GPS devices, drives and sticks… Further, many homes have their own wireless networks and centralized data – also under that same roof may reside multiple people with multiple devices – further compounded by multiple social networking accounts, multiple e-mail accounts, etc. In other words, an almost exponential explosion of end-points, portals, and avenues of potential human error in bringing breaching and harming incidents to fruition.
Consider the organization: What holds for the household is manifested through and by many, many employees. The avenues for potential breach and harm can number in the dozens, to hundreds, to many thousands.
On a local scale, just recently, the lack of a prudent, forward, view of security evidenced itself to me. A colleague’s auxiliary e-mail account was hacked, and subsequently used to disseminate e-mail advertising through the account’s group lists. But that’s not the worst of it – the free-mail account was of no great concern. However, this person used the same password for multiple accounts, including banks, and decided to change all passwords, and to make them unique to each account – a wise move.
Incredibly, one of his banks sent a confirmation e-mail of the password change, with the user ID and password for his account plainly spelled out. I thought those days were gone. Passwords should never be transmitted through e-mail.
Today’s environment means having a very proactive, provocative, security awareness. For organizations: Take survey of your end-points, your processes, your providers – a whole, 360-degree, view. Assign someone to assess vulnerabilities, and mount a plan that captures all devices and the nature of their use. Be sure to position yourself/selves for best security given your awareness and affordabilities.
Image credit: hueniverse.com