If you’re lucky the project staggers forward and meanders to a conclusion somewhere in the neighborhood of expectations. This is kinda one of those “bad boss” scenarios – after all, on the project team, this guy or gal is… in charge.
This person is going to make and adjust assignments. This person likely has input to your next rating if you’re a member of his/her project team (either as a temporary project assignment, or if you’re a permanent member of this person’s staff). Also, you have to negotiate with this person regarding resources, timelines, and deliveries. It’s nice if the PM is in your corner during the crunches (and vice versa), because you also have to negotiate regarding stakeholders and their expectations; both business people and other IT folks.
Oftentimes, you may find yourself exasperated – ‘How did he (she) get assigned this project?! He (she) has absolutely no talent for it!’ I’ve been involved with teams like that. I’ve had to rescue a few after the PM dropped the ball too. But assuming things aren’t falling off the edge of the earth, keep a few things in mind:
Bump the project along. If you have a strong project team, and there is trust among the members, then get a little aggressive – everyone can start to push – there’s strength in numbers. I’m not saying to go behind the PM’s back, but push the envelope.
Hey – ya gotta do something, right? Stay within the law, don’t step on any feelings if you can help it, and it helps to remember the alternative: Watching a lousy PM maneuver the project out into left field. Don’t let that happen.
Of course, the PM’s boss is likely to notice something awry. If you ever get called in by a level of oversight that is above your boss (project or otherwise), be factual. Don’t sugar-coat anything, but also be very serious and empirical. Give examples. Don’t come across as a back-stabber (even though your opinion has been solicited).
Once a specific level of management is soliciting opinions regarding a middle-manager, a change has pretty much been decided upon, so the gentle push of truth will serve here.
NP: The Doors: Essential Rarities. Rest in peace, Ray.]]>
Washington, D.C. had an interesting project failure just a few short years ago. They “paused” a project involving a mobile computer system for their fire department. The District lost between $4 million and $6 million during the course of a year and a half’s mismanagement. Part of the project’s confusion lie in the fact that there was a period where the fire department and the city’s Office of the Chief Technology Officer could not agree on who was in control of the budget – and therefore who controlled the project. That represents a fundamental misunderstanding, and a pretty big divide.
The specific insight in this case is to recognize that there is no such thing as a “paused project.” Once large-scale activity is halted, it ceases to be a project by any reasonable definition. Once you stop work, you lose your timeline, all milestones, control of budget, and your lock on resources. Evaporating too are expectations, definitions, and your anticipated implementation. You’ve lost control of the solution – to issues, challenges and problems that the project was meant to address. And remember – the so-called ‘paused project’ is berthed in a larger environment that does not pause its change. There is no such thing as a “pause” within a managed, true, project. What of the “go-live” date? It’s lost – a new one must be established in these cases.
Once a project stalls, you have a strong clue that you may be trying to shoehorn a False Solution.
We don’t mean to pick on government here – we mean to help government – and you. There are large-scale business and systems failures in private and public organizations large and small, and these failures are avoidable:
True solutions match fully exposed, and fully understood, hard business requirements – and they are implemented on target, on schedule. Budgets are known, sanctions are tethered, and all aspects enjoy clear definition as to who controls various elements, to include the ultimate responsibility and steerage for the overall project.
Your Business-Technology Weave must execute proper exposure of need, proper planning, and carefully managed adjustments and delivery. Properly executed projects, no matter how large, develop a self-reinforcing energy that lets all participants know they are progressing down the right path. These participants have set their sanctions, set their sponsors. They have aligned their resources. All sides have exposed and agreed to expectations, are meeting true requirements, and are doing so with appropriately sized solutions. Properly mounted projects are not constant pain, constant confusion, and constant rehash of issues that were supposedly decided at the outset of the project. This is a crucial understanding for your BIT team, and any specific project management teams. All levels of leadership and control in your organization should know what to do, and what to look out for and correct, at the outset of solutions and projects.]]>
The FBI crafted a false route (project) with VCF, because they didn’t know where they were – their point of departure (their actual liabilities and requirements); and their “Where We’re Going” destination did not reflect a true solution to the business case. This happened because of a failure to understand and expose true requirements. Theirs was also a failure to set expectations in a language common to all necessary parties, in mounting a successful, properly defined, project.
Let’s learn something else here: What differentiates VCF as a false solution vs. a poorly managed project? VCF was in fact both, but here’s another important lesson. If we take the Department of Justice at their word, we know that VCF had poorly defined (and evolving) requirements. There’s no way to match solutions to poorly defined requirements – that is fundamental. And, these poorly defined requirements were moving (evolving) – everything is changing. So, any solutions that were being worked and attempted had to be divided from what was actually required: hence they were false.
We know too that there were “overly ambitious” schedules. Schedules themselves are solutions; solving requirements for delivery of resources, for getting people together, for achieving consensus and progress, and for delivering solutions according to expectations.
An unrealistic schedule represents one that can’t be adhered to, and therefore is a false solution in and of itself. Think of it this way: Building an overly ambitious schedule is no different than relying on a calendar with 35 days per month. Neither reflects reality, and will ultimately compel you to fail.
Divides spawn divides. False solutions present themselves at all levels of the organization, within all strata and disciplines of a project, and often times small, not easily determined, falsities aggregate and contribute to the ultimate, overarching False Solution.
The conclusion for the FBI was that four years after terrorists crashed jetliners into the World Trade Center and the Pentagon, the FBI still did not have software for “connecting the dots”, and wouldn’t until Sentinel was finished and serving last year. Even then, Sentinel suffered fundamental project flaws: legacy hardware caused the system two critical outages. Emplacing new systems on outdated infrastructure and architectures is an easily avoided problem – at least it’s a simple one in terms of understanding. Match infrastructure to the overall solution’s requirements – it’s not mysterious. Ensure spec of physical spaces, server requirements, storage, processing power, bandwidth, hosting, access points, end-user enablements, etc.
Quote of the day:
I figure if someone at a party asks what I do, I can earn a valuable status upgrade by saying that I digitize tag clouds to e-enable infomediaries and engage data-driven long-tail folksonomies which harness rss-capable platforms and envisioneer cross-media functionalities.
- Matt Labash
Next: False Solutions can have False Projects]]>
The VCF was intended to automate a largely paper-based system of case files involving potential terrorists, targets, and allied information. Former 9/11 Commissioner Tim Roemer had characterized the FBI’s pre-9/11 case management as “index cards” and “typewriters.” That’s pretty difficult to believe for 2001, but there ya go. Clearly it was difficult to share and leverage intelligence in such an environment. The FBI had a true need to implement a modern system that would allow agents and intelligence analysts to share information in the successful resolution of investigative work. The overall goal of automation was a bona-fide need – the FBI had been criticized post-9/11 for “not connecting the dots” in time to prevent the attacks (essentially, they had an inability to manage and leverage dispersed content – information – intelligence).
Despite the necessary goal of automating the means by which to facilitate workflow, to search on information, to manage cases, and to provide reports, the FBI somehow managed to maneuver this project to a complete stall, and turned it into the ultimate “throw away.” For, while VCF was deemed “critical” to the war on terror, after four years and almost $300 million the FBI ended up with 700,000 lines of bug-ridden code. The system was so dysfunctional and far-removed from business requirements that it was scrapped. VCF has been replaced with a new project, delivered late last year – Sentinel – which (happily) survived despite fundamental flaws in project management and execution. But back to VCF and those lessons -
The U.S. Department of Justice’s Inspector General, Glenn A. Fine, released an audit that cited factors that contributed to the VCF’s failure. Some of them were:
One could well ask: What served as their Business Implementation Team (discussed here in past articles), or did they even have something for that role? Further, in looking at the list above, what was their Project Management Plan/Framework? It was sorely lacking, or perhaps even missing. It is actually quite easy to understand the FBI’s failure here: ever more effort was expended on going back and fixing things versus effort toward moving forward. They lacked an understood point-of-origin, crafted a false route, and never reached their destination.
Next: Some insights.
NP: Jimi Hendrix, Hear My Train a’ Comin’ – 12-string acoustic version.]]>
Well, not to sound too smug. I’ve had elements of projects fail: Missed milestones; sub-deliveries that weren’t optimal – that had to be re-engineered; angry blow-ups by key personnel in meetings (IT staff, vendor personnel, and… yours truly. But in my case, it was justified; honest. No, really…). But on balance, most of the projects I’m involved with, whether as the lead, or a team member, progress quite satisfactorily and ‘go-live’ is on-time, and on-target.
Not to say that projects aren’t challenging: Every single one I’ve been involved with has been very challenging at a minimum, and vary upward – that is the nature of projects, and project management. But I know colleagues who have had disasters on their hands, and I’ve seen high-profile projects go awry too – newsworthy items.
What are the main reasons, and what can we do to mitigate risks?
In the meantime, remember to maintain solid support to present systems and statuses, as you drive toward the golden solution.
NP: John Coltrane; Blue Train. Original vinyl (of course).]]>
As concerns ANY vendor or solutions partner, be sure to meet at their location from time-to-time – not just during an initial vetting of any particular solutions partner – but go to their site for meetings throughout the project – and judge the general culture and “feel” of the place. Does it look like a harried environment? Or, hopefully, are people focused, balanced, and seemingly productive? If the site looks and feels like a stressed environment (beyond the usual healthy tension), then you’d better re-evaluate your preferred vendor list.
In all cases, determine what caused the missed delivery(ies). Execute the clauses in all relevant contracts that trigger penalties for missed work (such as rebates, discounts, etc.) – hopefully you have those, but if not, be sure to craft future contracts this way.
Is the vendor solely to blame (or perhaps not at all)? Are there people or departments in your organization that are not submitting key deliverables to the vendor on time? You can’t penalize the vendor, or negotiate discounts, etc., if that is the case. Find the point(s) of failure and correct. As to the core of projects, stick carefully to milestones and statement/scopes-of-work. If there are change orders, and negotiated additions to the original project, make adjustments in your project management software and in reports, so that changes to the speed and direction of the “river” of the project do not show up as budget overruns and missed deliverables – it is not fair nor accurate to classify adjustments and additional work that way. (However, if poor project planning on the part of your organization exists, perhaps in the form of a poorly defined project, and related Request for Proposal [RFP], then this unfailingly results in a good-faith vendor Proposal, but one with poor match to your true business/IT requirements. The org suffers, and is at fault, and missed deadlines and a wobbly project should reflect in reports, so the org can learn and not repeat these mistakes).
If the vendor is truly remiss, then pilot the current project to successful conclusion as best you can, and write this vendor off if possible. If it’s a project that involves a central solution to the enterprise, like a core-business system, and it’s a vendor that’s virtually interwoven into your enterprise, then you’ll have to do the diligence with contracts and accountabilities. Possibly get some measure of your senior executive class to engage with theirs, in order to set some expectations for future engagements and progressions – and hopefully fulfillment of expectations for true adherence to milestones, project expectations, and deliveries.
When ironing out difficulties, maintain maturity, focus, transparency and communication. Learn from difficulties, and use them to improve contract documents, project management systems, early warning indicators, management of personnel, and reportage.]]>
How best to manage team members who are afraid to commit to tasks?
Background information showed the central fear being one of committing to a schedule. Generally, most folks working in IT, in any capacity, can predict with a fair amount of accuracy when they can have a task, project, piece of work – whatever – completed… if they are experienced. It helps if they are familiar with the nature of the work – but they usually are, or close enough, if they are the ones selected for assignment in the first place.
Those folks who lack experience – either generally, or according to specific piece of work – can be skittish about committing. However, schedules do need to be set, and often times tasks support much larger efforts: The project-whole; a key module’s enablement, and thus business’ enablement; a critical update, and so forth.
In the case of subordinates, working under a manager or team leader, who are reticient: You must meet with them one-on-one, and explain the importance for setting some sort of marker. Confide some unease that you had early in your career, and what you did to ensure things worked out – and they did! Commit to helping the trepidatious person if the going gets rough: “We’ll get you the resources and help you need – we’re a team.”
Emphasize the “team” aspect – both in terms of support, but also in the critical sense that the team needs this person’s best engagement, analysis, commitment, and delivery-to-schedule. It’s all a part of growth.
It’s essentially an opportunity – and sell it as that to the fearful member. Step up, move up, step up, move up… Even for folks who desire to remain static in their IT career – the world does not. They have to evolve, learn, adapt, and take on new challenges regardless – so they’d better get on it.
Afraid to commit? In IT? Nah – not an option.]]>
Agree or disagree: Many people list Project Management as a skill, but have no certification to support their claim. Does this bother you?
The short answer is “No.”
“Education is what is left after you’ve forgotten everything you’ve learned.” – Albert Einstein.
Certifications can make some hiring authorities feel comfortable, but experience is everything. A PMP certificate doesn’t accommodate organizational politics (certainly not specific environments), and may not delve far enough into the greatest challenges for any endeavor: People. The rest (the mechanics of PM’ing projects, and acclimating to specific ones upon assignment) is a piece of cake, comparatively speaking.
In my case, I’ve managed large capital projects, and written frameworks for Fortune100 companies as well as Pentagon agencies. I have no project-related certs and doubt I ever will. I’m strictly experienced, having worked my way up by the seat of my pants, starting small, and graduating to larger and larger projects (and larger and larger enterprise environments). Nothing – NOTHING – trumps experience, knowledge and, in particular, wisdom. That’s not to say that someone with certs is discounted – but they have to have the practical experience to go along with that before I’d ever call them a true Project Manager.
I would never screen someone from consideration who is minus a PMP – however, I do look to schooling and degree levels in general – it shows discipline and the ability to reach goals. Recognize too that, depending on when any certificate was issued, it’s going to be out-of-date fairly quickly. Unless a person is taking refreshers (some of which may be necessary for maintaining a certified status), then “old” education may actually be inhibiting.
Give me someone, anyone, immersed in IT that has common – make that exceptional – sense, and I’ll give you a Project Manager. Maturity, focus, confidence (absent arrogance), social skills, ability to prioritize, and ability to compromise are measures not often embodied in single individuals.
But, when canvassing IT – those are the people who make good project managers, certs or no.]]>
With the failure rate of IT projects so high, what should the CEO do about it?
The questioner appears to be taking the burden of project oversight from the CIO (and assigned PM), and [mis]placing the burden for “fixes” at the door of the CEO. The questioner’s argument then follows that “the money belongs to the enterprise” (true), and “If the CEO isn’t involved enough to know whether there’s a problem, then the one person in the organization who could fix the problem would apparently not care to get involved…”. (This line of argument would seem to indicate that a sugar-rush of $$$ is all that’s needed to ‘fix’ projects – whatever the remiss). Advice that the CEO be somehow more involved (with a money trigger?), is followed by a further suggestion that all PMs answer a daily, online, question as to whether any specific “xyz” project is “on schedule” and “on budget” according to specifications. Presumably the CEO would have the administrative duty of reviewing all project reports!
Couple serious problems here: C-class executives, to include CEOs, CIOs, CTOs, COOs, CFOs, etc. – rely on PMs and other qualified people to steer, adjust, and deliver projects. C-class folks are maneuvering pretty large business and tech variables. If the CEO is “the one person in the organization” who can fix a project, that org is in deep trouble.
Further, the questioner assumes that money (and the CEO’s ability to apportion/dispense that money) is all that’s required to “fix” projects. Not so.
Plenty of expensive project failures are out there, harboring generous budgets: Many have money lavished on them, to no avail. Besides, part of any project’s definition is… THE BUDGET – arrived at through prudent examination and a defined scope of the project. That’s the whole point of “projects” and “project management.”
Project failures result from poor project definition (What is our present position? Where are we trying to go? What do we need, and need to do, to get there?); poor oversight; unrealistic expectations (resulting in unrealistic milestones), missed deliveries, push-backs on goals, and either a late “go-live”, or a project that crashes and has to be re-mounted, with adjusted goals and deliverables.
No CEO is in a position to “fix” projects – if he or she was, there’d be an enormous breakage in the org chart and related discretion of duties. CEOs (and the org) employ people to fix projects, and those people are there to keep “project fixes” off CEO’s backs. Recognize too that CEOs cannot merely lavish money unconditionally to lagging projects (whether more money is justified or not). CEOs answer to budgets, to boards, to outside partners, and to regulatory oversights both internal and external.
For projects that are wobbling off balance – with missed deadlines and zooming expenditures that eclipse budget elements – it’s clear that they do not enjoy effective project management. The org needs a solid refresher for how to mount projects, manage them, and deliver them.
PMs and CIOs/CTOs should not embarrass themselves at the door of the CEO. Rather: Know, and do, your job.]]>
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.]]>