Thoughts and observations on the intersection of technology and business; searching for better understanding of what's relevant, where's the value, and (always) what's the goal ...
Business Proposals and The Lesson of Jabberwocky
When someone asks my opinion on their writing, I'll get fairly detailed; I've noted in the past that there is a lot of
power and influence in the written word, and it's fairly important to get it done well, or your project proposals just never seem to get off the ground.
This particular proposal suffered from a lack of direction; it didn't take the reader (the decision maker) through a clear progression. Admittedly, the subject matter was a bit technical and mildly complex; even though this was a proposal for internal IT eyes, the prose didn't flow, and did not help the reader understand what we are asking for, and why.
I suggested that the subject matter - highly technical services - shouldn't impact the difficulty we were having in getting the basic idea across. A good way to validate the structure and effectiveness of a written proposal might be to show it to your high school or college-age children. The document should make a cogent argument that a reasonably intelligent person should be able to understand;
it doesn't matter if they understand the technical specifics!I saw Alice in Wonderland a few weekends ago, and noted that the plot takes a lot from
Jabberwocky. Now, I'm not a "Carroll scholar" by any means; I recognized it, was even able to recite most of the lines - but I blame my high school English curriculum. It was [way] back in my sophomore year - we spent a week or so deconstructing the poem, and the teacher pointed out that you don't need to understand exactly what a jabberwocky is, or what a vorpal blade looks or sounds like - you can identify these foreign-sounding words and concepts (a Jabberwocky is a noun, vorpal is an adjective, and snicker-snak is an alliterative, sounds-like description)
in context. You understand the story and the drama in the poem without completely understanding the specifics in the dialog, because it is a well constructed story.
The same goes for this technical proposal. This should be an effective writing piece made to educate; a business proposal, arguing for action or caution, must make an effective argument. The document's structure has much to do with the success or failure of the proposal - technical details are for a secondary, deep-dive pass, but the basic business argument should be apparent.
Historically, we have seen X
Recently, Y has changed, to Z effect (X is worse than before)
If we take action Q, we can get back to X.
Q will cost J dollars, and bring K benefit within L months
Currently, we are at The As-Is .
Future state will be The To-Be.
We can get there from here if we execute The Action Plan,
at a cost of A dollars and B people's time over C months.
External Event Alpha requires us to be at future state Beta
We have two alternatives:
- Plan 9, which will cost 10x and require 1 dedicate Framistat - and be delivered in a year
- Plan 10, which will cost 100x and require 5 dedicate Framistats - and be delivered in a month
Due to Factor Gamma, we recommend Plan 10
As a good common sense check for your writing effectiveness - run it past someone outside your team, someone with solid business sense but not necessarily a deep grasp of the details. There are many patterns for laying out persuasive arguments; learn them, before someone takes a vorpal blade to your next project plan.
Previously ...Technorati Tags: documentation, marketing, PMO, project management
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan
Labels: communication, documentation, Knowledge Management, PMO, project management
If I Told You a Fractal Solution, Could You Change the CEO's Mind?
As the new year approaches, debates over the "value" of IT and business projects intensify; it's not holiday stress, but the excitement of the approaching New [fiscal] Year. Lately, I'm hearing more about the struggle to quantify business value, especially when selecting those few projects that will "make the cut". We will definitely iterate on our scoring framework, adding a cost / benefit template to facilitate more apples-to-apples comparisons between projects (
yes, don't scoff - it is possible - more in a later post ...)
However, I think there's an interesting vision in some people's minds; a sort of value-optimization Utopia where, even with hundreds of project ideas on the list, the executive team has the insight and ability to select the best projects and fund them appropriately - as long as they all have business values assigned.
I don't think assigning a value to every proposal is realistic, and certainly not something to aspire to - well, not directly anyway. There are a number of significant hurdles to deal with - the reluctance of people to commit to hard benefits, the lack of suitable productivity metrics for new technologies and methods, and the difficulty of communicating innovations to those who didn't think it up on their own (ie.
close the patent office, we're done).
Yet, even if you did address all of those problems, and could easily measure impact and communicate effectiveness on 300+ terrific project ideas - how could anyone to claim the ability (or the time!) to rank such a list from "best" to "worst" (or, since I don't propose projects are bad to begin with - "most best" to "least best")? Truth is, they don't - most of the business leaders I've worked with have no interest in looking at 300 projects, and would be a tad perturbed if I tried to get them to peruse such a list. Do you appreciate it when your teams bring a thousand problems for you to sort through?
Rules of ThumbMost people have a favorite way of
eating their elephants. Yes,
one bite at a time - but where to start? How to carve?
Deliver Small, Iterate, and Evolve: The
agile among us would focus on short-term deliverables with small measurable steps to make incremental improvements. Speed and iterations will drive the quality and help focus on those areas of work that have the most short-term promise.
Focus on the Big Rocks: The biggest and toughest problems - or the projects with the most benefit - are sometimes so daunting that they intimidate us into dealing with "the easy stuff". Clear your calendar and tackle these larger opportunities first, else you'll never get to them.
Focus on the Constraints: Understand which resources are keeping you from launching multiple projects at once. These are typically people - in key positions, with monopoly knowledge. Simplify things by
prioritizing their projects first - but strongly consider launching efforts to remove the constraint, by having them document, train, or automate their knowledge.
Practical Problem SolvingAs I proofread this post, it sounds like a checklist for common sense; no surprises, just a different level of detail depending on the organizational level you are speaking with. It's important to understand the
fractal nature of business challenges; no matter where you stand in the organization, the number of items on your ToDo list (and/or the number of challenges you are
juggling) is roughly the same. The sooner you can put yourself in the other person's shoes, and speak to them at the level of detail they (not you) need - the more effective your conversations will be.
Besides, they're paying you to solve problems, not define them.
Previously ...Technorati Tags: business value of IT, documentation, innovation, Knowledge Management, people management, PMO, project management
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan
Labels: business value of IT, communication, documentation, innovation, Knowledge Management, people management, PMO, project management
Collaboration "in the Wild": Some Observations
An Enterprise 2.0 dream scenario: implementing a complex project across multiple sites, in two different time zones, with a large team (well over 100). The team was reasonably savvy with collaboration tools; core team members were quite comfortable with Instant Messaging, and we have been relying on SharePoint for many months. A centralized, coordinated document repository; a single source, very public bugs/issues list - the foundation was in place for some time, so our "go-live weekend" experience was pleasantly predictable.
During this critical time, we had to coordinate with the multitude, and we did that with a highly structured "hour-by-hour plan", regularly scheduled "all-hands" conference calls, and web-based meeting places so all could review Completed, In Process, and Coming Soon tasks. After a successful weekend, we received plenty of positive feedback, and some interesting suggestions for improvements:
- Conference calls were regularly scheduled, and featured tight agendas - which tended to limit individuals' ability to connect with the right person (until afterward). Since each location had a "war room" where the team gathered for the status calls, some suggested we leave the conference call open 24x7. I wasn't a big fan of this one, primarily because I'm the guy paying the long-distance bill ...
- Few on the team are actively using Twitter, but one of the project leads noted that IM was quite popular, and imagined a Tweetdeck-like ability to see instant messages and responses that have gone out previously; "threaded conversations" that could be visible to all, helping collaborative problem-solving and knowledge transfer. I congratulated him on inventing Google Wave ...
- Like most decent-sized companies, we have a highly structured Process for approving code changes into production - and like most decent-sized projects, we noted a few instances where promotions to resolve problems were delayed (while they worked their way through the Process). Might there be some streamlining opportunities here, since we are working on a high profile project with lots of oversight?
Of course, #3 was a non-starter, but the first two generated some good discussion, Yes, it's conceivable that we could augment our SharePoint site with a few new extensions or plug-ins to address the first two - but I'm actively working against any changes to our collaboration environments for a very simple reason -
we're not finished with the big project. Phase 2 of 2 is coming in just a few weeks.
Am I being
close-minded? Not really, I'm a huge driver of collaboration tools in the company. But, I'm also a realist - and I know two significant factors that argue against change at the time:
Prioritizing "Improvements": We are implementing ERP and other highly intrusive / foundational systems, and there's a lot of change that comes along with that. I understand that an organization can only take so much change at once - so why not focus on the stuff that's bringing real (ie. quantifiable, bottom-line, significant) business value.
: Eight months ago, sharing files by e-mail and ad-hoc, unstructured meetings were the norm. To be fair, we were working smaller projects with teams of 10-20, and usually in no more than two locations. Over the past few months, as we were teeing up for Big Go-Live #1, we've been introducing the newer tools in small bits. For Go-Live Weekend, the team was already familiar with going to SharePoint for status updates, or recording a new Issue in the SharePoint list. The mechanics were old hat, and folks didn't need to think about it - which was nice, since we need them thinking about their Tasks. If we introduce new collaboration tools with little lead time before the Big Go-Live #2, Tasks will be interrupted with people struggling to remember how to communicate.
In the right setting, collaboration tools can clearly add value - even for the most conservative jaded technology users. However, you can't introduce something so new and expect people to "get it" in the short term. Better approach is to introduce the new tools early in the process, when there is no pressure. This lets the team build familiarity, understanding, and skills by the time you need to rely on these tools for critical communication.
Previously ...Technorati Tags: collaboration, entrepreneur, innovation, Knowledge Management, people management, project management, SAP, Social Networks, twitter, Web 2.0,
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,
Labels: collaboration, communication, Google Wave, Knowledge Management, PMO, project management, SAP, Social Networks, twitter, Web 2.0
Real Business Users and SharePoint
Introducing buzzword-compliant technology like a wiki, or integrated collaboration spaces like SharePoint, will typically go well with a motivated audience like your internal IT department. But if you really want to understand how this stuff works, try it with "real people" - line employees in sales and marketing, operations, and finance.
Sure, you've heard complaints from these folks (they have better PCs at home, the SAP/Oracle UI is brutal compared to Amazon and AT&T U-Verse, and why can't they just connect their new iPhone to the corporate mail server?). Be warned; demanding users are not necessarily technically savvy when it comes to groupware.
Case in point; we are working a rather large project (many months in length, over 100 people throughout the business) using SharePoint as our collaboration space - and learning an awful lot about what we
thought we understood about ease-of-use and intuitive user interfaces. Our collaboration space is a basic SharePoint project site, featuring the usual suspects - a Shared Document library, an Issues list, and an Announcements section. Simple right? Well, maybe not ...
Documents Check In, but they Don't Check OutJust kidding, the actual check-in / check-out mechanism works fine. It's just very interesting that this basic concept of version control is lost on most end-users.
But let's start with the document library itself - it looks like a really nice version of File Explorer, but becomes very frustrating to folks when they try basic tasks like drag-and-drop. Yes, we found the simple solution - there is an option to open the folder in Windows Explorer, but since this menu option is buried right above the file list, it's hard to find - certainly not "intuitively obvious".
Version control was a difficult thing to explain - thank goodness for the tight integration with Office 2007. We found it easier to show folks how to edit documents with a simple double-click - that works just like their shared folders on the old file server! You can explain the concepts of version control quite easily, but the whole check-in / check-out, keep-a-copy-on-your-local-drive thing just gets too complicated. We did have to deal with the one-time task of checking in a new document after you upload it, but after that, they just open the files directly, and that's it.
There is one feature of Shared Document libraries that I really like - the ability to add custom attributes to documents that can appear as columns in the view. Makes it easier to sort / select / search on documents, and people "get it" relatively quickly. Just go easy on the version control.
... Here's a SharePoint TissueI think the most powerful and elegant feature of SharePoint is the flexibility you have with basic list management - even with WSS. Truly, this stuff should cover over half of the "fancy" automation tasks that folks are are asking for. However, I'm still surprised / dismayed by the fact that SharePoint doesn't include a standard graphical indicator - you know, the classic "stoplight" (green is good, yellow warning, red means um, er...). I've written about this one
before - why can't I have a simple datatype (vs. putting together a
sneaky little script to make it work).
I also have a significant warning / insight about trying to do too much with your Lists. Do you realize that most end-users in a typical SMB have older CRTs? I'll bet you still have a large number of 15" CRTs with slightly foggy tubes, on their last legs (but too expensive to change out for all but the executive staff) (ok, and IT too, sorry). In addition - well, let's just say that I'm not the only one whose eyesight is
beginning to fail them; I can't tell you how often I've tried to talk folks into moving their screen resolution higher than 800x600 - but it just doesn't work.
What's my point? Before you put too many columns in your Lists, or too many gadgets on your Site, check with the average user to make sure that it looks okay on their Screen. Heck, before you even begin your design, use SMS or a simple script to poll the user community and find out what kind of screen resolutions have been set. Catering to the lowest common denominator is not a cop-out, especially when the point of a collaboration site is to get people to actually participate!
Push vs. Pull Messaging(Another opinion:) I think most powerful aspect of collaboration sites is the aggregation of all knowledge about a project into a single, searchable repository. When people send project updates or resolve issues / hold discussions over e-mail, all that knowledge is buried and quickly lost inside people's inboxes. In SharePoint, a typical Announcements web part (yes, I know it's just another kind of List) is quite practical as a messaging medium, because folks can sign up for e-mail alerts.
Don't underestimate the attraction of the e-mail. People are used to getting information delivered to them in their inboxes - it's expected! All I'm saying with my Announcements list is that you have to subscribe to the information and pull it towards yourself (versus expecting me, the project manager, to remember to push it to you - and everybody else that might be interested).
Real-world learning: this concept didn't take long to grab hold in our project. It makes sense, people understand it relatively quickly.
On The Good SideDon't get me wrong, there is lots of good that's going on. Now that the larger project is getting used to this new collaboration space ...
- ... our issue tracking list gets better every time someone touches it - and now we have consistent consolidated issue lists for all aspects of the project
- ... we are advancing our state-of-the-art for shared authorship; there is a lot more visibility to who is working on what, and we're getting more participation than a normal project
- ... the combination of all these different pieces - shared documents, issues, announcements, and other things - are massively facilitating communication, and it is noticed by the folks on the team
Yes - these collaboration tools will definitely will bring huge value and streamline communications to your project. Just don't think it's easy or obvious.
Previously ...- Update on Blogs as PM Tools - Tales from the Front Lines (January 20, 2008)
- Butting In to the Conversation: PM Communication Tools (February 26, 2008)
- The Best Way to get Web 2.0 Into the Enterprise (March 3, 2008)
- Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
- The Innovation Generation and User Interfaces (April 9, 2008)
- The Right Web2.0 Tool for the Audience (Twitter, LinkedIn, Facebook) (May 9, 2008)
- Enterprise 2.1: Exiting the Trough of Disillusionment (July 22, 2008)
- Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
- Is SharePoint WSS dangerous to SharePoint contractors? (February 4, 2009)
- Low Tech SharePoint Hack: Project Status Indicator (March 14, 2009)
Technorati Tags: collaboration, hands on, Knowledge Management, people management, PMO, project management, technology, Web 2.0, wiki,
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan,
Labels: collaboration, communication, design, documentation, hands on, Knowledge Management, people management, PMO, project management, SharePoint, Social Networks, tech management, technology, Web 2.0, wiki
The Delicate Art of Pushing Back
Commiserating a week or so ago with an old friend, struggling mightily with some external consulting firm providing technology talent, developing customer management systems for Big Sales Company. There were some critical dependencies on the server side, and the (internal) project team needed some on-site assistance working through the issues. Ad hoc phone support was just not cutting it - but the external project lead was pushing back. It's very difficult to get on-site, dedicated help for these in-demand DB technicians with little advance notice. My friend would have to wait a few weeks - which did not sit well, hence the commiserating.
Of course, I could easily see his counterpart at the consulting firm venting over his own frosty mug; I myself would feel ill-used (to some extent), because it’s not really reasonable for Big Sales Company to ask for something immediate like this – you just don’t turn these people on and off like a faucet.
I [politely] note that my friend is not the greatest at diplomacy, especially when dealing in shades of gray. He gets too specific, too black-and-white with his thinking; I really don’t think he’s empathizing with the components / teams he needs to work with to get the projects done. They are the subcontractor, the subordinate - he just wants to tell them what he needs, and expects them to hop-to and get stuff done. Don't define problems, define solutions, yada yada.
That’s not always the most effective way of dealing with the situation; it helps a lot if you can empathize some with the subcontractors / subordinate / supporting teams’ world. Understand the tasks you are asking them to do - so you know when they are sandbagging, but can appreciate when they are committing to getting some really significant stuff done. Don’t just tell people what to do – work together, in a partnership.
But then, as I said this, it occurred to me that this was all just a reflection of how this person manages up when working with the business. Ok, he's a bit older than me, so after all is said and done, he still thinks the business can ask for anything, can put any wacky requirements out there - and IT just has to figure out how to get it done. Of course, what's good for the goose is good for the external consultants - the frustration stems from the fact that the consulting firm is not behaving the way he thinks he would behave, if put in the same situation.
This is wrong on many fronts. IT needs to push back on unreasonable requests, if only to set the right expectations for what can happen. We need to help the business differentiate between what they want and what they need, to drill into root causes instead of fixing symptoms or papering over the tough issues.
The best PMs are good at managing up and down; pushing back (respectfully and constructively) on the project sponsors, and working with their supporting teams, not telling them what to do.
Previously ...
Technorati Tags:
collaboration, innovation, people management, PMO, project management, tech management, vendor management
Invisible Technorati Tags: cazh1, James P. MacLennan, jpmacl, MacLennan
Labels: collaboration, innovation, people management, PMO, project management, tech management, vendor management
Over / Under Communication for Project Managers
It is often said that you can't
over-communicate, but I'm willing to bet most folks - and especially your project sponsors - underestimate the cost and effort of this critical component of project management. Consider this fair warning - and a good checklist for folks wanting to get into IT, project, or functional management.
MediaTo achieve any decent amount of success, you have to be a good communicator with both face-to-face and written / published media.
And by "good" I mean both "comfortable" and "effective". You should feel good in your own skin, confident that you can carry a conversation at all levels of an organization. And you also have to be an effective communicator - able to get your point across with the right amount of detail, not too much or too little. Another effectiveness challenge is the ability to balance between personalized, one-on-one written & oral communication, and insightful, understandable mass communication.
TranslationsYou may not realize how many different "languages" you speak - and effective managers must be reasonably fluent ...
- Languages - Finance, Operations, Sales & Marketing; business groups have just as many confusing specialty words as the techies in IT
- Dialects - Do you speak Oracle or SAPanese? Experienced in small companies or large corporations? Public vs. private? Entrepreneurial or slow growth? High volume low profit FERTs, or low volume, high margin custom products? The concepts are all the same, but sometimes the specific words are different.
- Slang - Slightly different than dialects - all companies, organizations have local shorthand term so that over the years in their particular organization to mean very specific, nuanced things.
- Sound Bites - A form of speech where a complicated topic is reduced to a single word or phrase. For example; ATP. Are we talking about master data, settings on time fences, the process of checking for availability, or the policies around A, B, C and D companies? Sound bites can sneak into conversations and you could be discoursing for 15 minutes before you realize you're talking about two vastly different things.
- Strata - Management v. line, Middle v. executive management. Depending on what level of the organization you're talking to, you will need to change the level of detail that you go into. Typically, higher up in the company means a lower level of detail that they want to wade through.
Change ManagementVolumes have been written on this topic, but most people have trouble coming up with a concise definition of what this means. To oversimplify - but drive right to point: change management is typically about delivering "bad news".
However, "bad" can mean different things. It can be "disappointment": the date will slip, we're over budget, or we can't fit this feature request into the schedule. However, adjusting expectations as early as possible is one of the basic skills of a good project manager. You need to be willing to deliver bad news like this as early as possible.
The other significant area of "bad" - walking into an organization, a group of people, or a individual's cube, and letting them know that the way they have been doing things for years is about to change. Sure, it's easy to say that "change is hard" and "change is inevitable", but you yourself probably don't like change in your established rituals. Empathy is the key here.
Lessons LearnedAs with many other things, the more project communication you do, the better you get. Some of the more common lessons learned:
- Defensive project teams will often negotiate for delay by asking for / waiting for More Communication, and complaining about Not Enough Communication
- In any project plan, you will underestimate the time required for communication, the number of times you'll have to repeat the message, and the ability of the team to consume your communication in various forms of delivery media
- You will definitely underestimate the time required for follow-up and follow-through to make sure it's Done
- You will overestimate the amount and quality of existing documentation, and the ability of the project team to bridge the gap to the required level of documentation
Here's the killer -
- If you try explaining to management about the problems / challenges of communication, they won't listen and/or won't understand (yes, that is a tight loop)
Machines will never replace us - but this is one case where sometimes, you might wish they could.
Previously ...- Communicating Complex Technical Concepts (March 21, 2005)
- Euphemisms, and a career-extending paradox (July 11, 2005)
- Finding shapes in the fog - How to frame a wispy, wandering conversation (September 7, 2005)
- Three Best TLAs of all time, the hegemony of Excel, and the Intuitive Front End (August 12, 2006)
- War Stories from the Change Management front (August 21, 2006)
- Communication is the responsibility of ... (August 19, 2007)
- The Five Fundamental Rules of Project Management (October 15, 2007)
- Butting In to the Conversation: PM Communication Tools (February 26, 2008)
- There ain't much IT in IT Management (May 7, 2008)
- Can you, should you, bother Executives with The Details? (May 30, 2008)
- More On Executives (are Smarter than You Think; the 5 Biggest Misconceptions) (June 12, 2008)
- The Power of Paper in Business Communications (October 22, 2008)
- A Plea for Empathetic Communication (November 16, 2008)
- I Think I'm Learning SAPanese ... (November 22, 2008)
Technorati Tags: communication, documentation, Knowledge Management, people management, PMO, project management, tech management,
Invisible Technorati Tags:
cazh1, James P. MacLennan, jpmacl, MacLennan,
Labels: communication, documentation, Knowledge Management, people management, PMO, project management, tech management
PMO Nirvana is a Conversation, not a Schedule
We continue to iterate on our PMO processes - managing too few resources and too many project requests, an environment I have consistently seen in every IT group I have ever worked with. Our latest discussion concerned the concept of
FIFO work on projects ...
... when presented with five things to do, I will only [emphasis added] work on them in the order received.
This is an exceedingly poor assumption for your personal run-rules, and a short-sighted objective for a PMO that needs to be aligned with the business.
You can't assume or aspire that your PMO can be a finite scheduler for IT. There is too much variability, softness, lack of clarity, process, etc. on most projects – especially at the
Application Layer. Once you get anywhere close to business process and the fluid nature of business requirements, you have to have a strong element of agile, flexible resource scheduling and response.
<aside> One might say that the lower you go in the seven-layer stack, you have a better chance of finite scheduling this stuff – projects can and should be more highly predictable, highly engineered. </aside>
Another bit of the conversation uncovered an interesting insight; is there "too much" communication overhead? The effort involved to document something completely, to build a detailed work plan, to create a detailed, multi-line resource forecast – yes, these all represent large chunks of work that do little to make something happen on the screen / in the database. However, the value of such effort is quite high, because the results facilitate complicated conversations in the future. It’s just like the idea of capturing requirements early on – saves tons of rework later.
<aside> That last analogy begs a contrast to agile development - but agile values and requires focused communication and rapid iterations, which can be tough in an environment of thin resources and a high volume of "open" projects. Some elements of the classic waterfall are helpful when keeping multiple plates spinning. </aside>
A final quote - actually heard someone summarize the situation as "we just have a lot of slow projects". There are two important problems contained in that sentence - "a lot", and "slow". You have more
control over quantity and duration than you may think ...
Previously ...- End-around the Prioritization Process (August 14, 2004)
- Communicating Complex Technical Concepts (March 21, 2005)
- If you want to be more than a programmer, stop programming (April 8, 2005)
- Subdivide a huge project list to simplify the prioritization process (October 27, 2005)
- Documentation Redux - a Shorthand Proposal Framework, and the PMO Surprise (July 30, 2006)
- Driving to a Decision on your Projects (February 10, 2007)
- Thoughts on Why Tech Folks Need to Sweat the Administrivia Details (July 14, 2007)
- PMO Prioritization - Project Descriptions should be Effective, Relevant ... and Short! (December 9, 2007)
- How to Cheat at the PMO Prioritization Game (December 14, 2007)
- How to Win at the PMO Prioritization Game (December 18, 2007)
- Tactics for Controlling Project Scope (January 5, 2008)
- Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
- Rules of Golf - Project Prioritization Process Needs Clear Documentation (February 18, 2008)
Technorati Tags: business value of IT, documentation, PMO, project management, tech management
Invisible Technorati Tags:
cazh1,
James P. MacLennan,
jpmacl,
MacLennan,
Labels: application development, business value of IT, collaboration, documentation, PMO, project management, tech management
MS Project, Early and Often
99.9% of the project managers I know have at least
heard of Microsoft Project (MSP), and all understand it to be a very capable, yet very complex environment for estimating and managing projects. But it's Saturday evening and I'm a bit cynical tonight, so I'll say that 50% of those people don't really
understand how it works - and have many reasons why they should
not use MSP for this project or that ...
- ... this is an iterative development effort - not enough requirements to lay out a work plan ...
- ... gantt charts are inherently waterfall, and this is an agile project ...
- ... there are too many other things going on, and I can't (don't want to) model everything that these people are doing ...
- ... this is a simple effort - small team, tiny deliverables - MSP is overkill (the phrase "shooting rabbits with a bazooka" comes to mind) ...
Cynicism aside, I think the last excuse is the most common; unfortunately, this sets up a no-win situation. If we only use MSP for large, complicated projects, when will we ever learn the basics? This negative line of thinking is sure to take you down an unfortunate path that ends in Excel task lists and endless emails looking for status updates. A better approach would be to see project management as it really is - not so tough once you learn the basics. (
Add little to little and there will be a big pile - Ovid).
If you've ever used MS Project, you understand what I'm talking about - there are a large number of defaults to set up at the outset. Also, you need to understand the interplay between Resource assignments, Available Units, Task Type, Effort, Duration … and when (if ever!) to use the dreaded F9 (Level Resources).
Suggestion: start using MS Project now - even for the very small projects! It's like any other complex skill - the more you practice, the better you get. Why not work out the basic mechanics and concepts on simple projects; when the more complex ones come around, it will just be a step-function higher in difficulty. (Practice makes perfect, walk before you run, etc.)
Three follow-up ideas on this topic, building on stuff from previous posts ...
Document Standard Process: As you develop your skills, you will undoubtedly develop preferences for options / defaults, ways to make your projects behave consistently. Take the time to document this stuff!
Templates Are Our Friends: With more projects under your belt, you should start to see reusable "components", like standard blocks of tasks for server configuration, application testing, etc. Also - start to build your reusable list of resources, standard calendars that fit your organization, etc.
MSP and PowerPoint Are Not Friends: Gantt charts direct from MSP are
too complicated. If you must deliver project updates via PowerPoint, better to develop a simplified Gantt visualization using Excel or Visio (examples
here and
here).
Note: I have an Excel sheet I use to create Gantt "pictures" - not useful to track a project, but very nice to add a simple visual to a slide deck (click on the picture for a full-size image) ...
It's not really ready for "prime time", but let me now if there is interest - I'll clean it up and post it here.
Remember, the intricacies of resource, task, and cost management with MSP are the easy part of project management - frees you up to work on communication and change management - where the
Real Project Managers show their worth ...
Previously ...Technorati Tags: best practice, documentation, PMO, presentations, project management, tech management
Invisible Technorati Tags: cazh1, James P. MacLennan,
jpmacl,MacLennan,
Labels: microsoft project, ms project, PMO, project management, tech management
Sample Interview Questions for MS Project
Sample Interview Questions for MS Project
I still get interesting, unsolicited pings from the meebo widget on my blog site. I've got a Pidgin plugin that connects to meebo, so when it says I'm available, I am definitely at the keyboard, hacking away at something - and usually able to answer the quick message. Still, sometimes I'm amazed at the depth and detail of the inquiries.
Last week, I got into an interesting conversation with someone about MS Project interview questions. At first, I thought they were the hiring manager, looking for some material for their incoming candidates. Later, I found that this was a candidate, anticipating questions on their depth of knowledge in using the popular gantt-generator. Points awarded for being proactive! (note - he sent me his resume, so if you are looking for someone good, let me know ...)
I have published interview questions in the past, and have written/compiled sample questions for a number of programming languages - but I've never seen a decent check to validate if that incoming job candidate has some "chops" in MS Project. It would be a pretty handy thing to have - if a position requires experience with complex projects, such skills would be prima facie evidence that they can deal with complexity and rigor. Of course, it's not a direct indicator of their soft skills, but that's another conversation ...
So, I sent a request off to Andy Kiss, a colleague who has excellent PM and MS Project experience, and added his ideas to a quick eMail I threw together for my web-IM connection. Below, I've fleshed the Q&A out a bit, for your consideration.
As I created these sample questions, I noted many areas that do not necessarily have right/wrong answers. There is a certain art along with the science, and any experienced PM will have some (preferably strong) opinions about what works and what doesn't. You aren't testing for a specific skill level as much as a solid understanding of the theory and fundamentals, and war stories showing how they have applied these skills and made MS Project work for them.
Do you have a sample project plan you can walk me through?
Before they come in for the interview, see if the candidate can bring along a sample of their work. Ask them to bring in a paper copy, explaining that this should alleviate any concerns about distributing confidential or proprietary information in electronic format (they can keep the samples when they leave). Actually, you need to take a look at how they present a complex project in a relevent yet informational way (since review meetings with stakeholders typically take place over paper copies). How good of a communicator are they?
How do you add or delete a standard or custom column/field?
A bit of a trick question: there are many ways to add (or insert) a column/field, typically they will brute force Insert or use a macro. You should never delete a column/field that contains data; recommended approach is to hide the column.
Interviewer could drill in to the candidate's use of custom tables, views, fields, and filters. Have they set up templates? How do they manage consistency among multiple projects? Do they use automation or templates to develop standards and make incremental improvements for each project they work on?
Why would you embed contractor time within a Project plan? How do you do it, and where do you get the quickest information relative to contractor costs?
There are multiple reasons for contractor time, the most obvious would be the need to account for all tasks and dependencies. The candidate should also come up with a rationale around capturing cost - they need to demonstrate a focus on schedule and budget. It's also interesting to see where in the project proposal process they bring in high-level Project plans, with resource-loaded tasks and time lines, to develop initial estimates for the inevitable cost/benefit conversations.
Specifically, to get this done, you need to add contractor cost per hour on the Resource Sheet. Costs could be a blended rate (for High / Medium / Low skilled tasks) or specific rates for known resources. The candidate should be able to speak intelligently on how and why to create a blended rate - averaging hourly costs for full-time employees and contractors, the total project budget (when approved) gives you the flexibility (ie. the budget) to bring in external contractors when internal resources are occupied with other work.
How do you best embed resource availability within your plan?
Use a Standard calendar, noting non-working time for all resources. Then, embed out-of-office for specific individuals as needed. If you skip this step, you risk creating an inaccurate schedule, by hampering Project's ability to extrapolate accurate future dates.
You can sneak into a soft skills conversation here, by talking about the requisite negotiations for resource time within the business (I already have a full time job ... no time to work on this ...)
How do you model meetings and non-working time in a project plan?
How would you best configure the critical path to be very obvious within your plan?
Format - Text Style - Item to Change; Select Critical Path and adjust color to Red or something else equally eye catching. Extra points awarded if the candidate is sensitive to the typical lack of color printers in many organizations - how does your Red come out now, hmmm?
Here's another opportunity to move into a soft skills conversation, with war stories about significant critical path moments in past projects, or discussing how to explain critical path to the project team.
Explain how Earned Value fields are used to compute Schedule Variance - and why this is important.
Schedule Variance (SV) = Budgeted Cost of Work Performed (BCWP) - Scheduled (BCWS)
Cost Variance (CV) = Budgeted (BCWP) - Actual (ACWP) Cost of Work Performed
Project Earned Value is a simple concept (are we ahead of schedule? Budget?), but most folks don't use it. It's an indicator of how good the candidate is at tracking an active project (as opposed to just using MS Project as an estimator / high-level planner).
Can MS Project be used to track an agile development project, and if so, how?
There is no right answer to this question, I've heard opinions on both sides. However, if someone can give a cogent, detailed answer either way, they are demonstrating their knowledge of agile and/or Project
What are your favorite MS Project books / web sites?
Project planning, estimating, tracking, and communication are possibly the most complex, nuanced area that Microsoft's family of Office-related applications hopes to support. Experienced, professional PMs should be actively looking to expand their skill sets with a variety of resources.
Have you done any VBA automation with MS Project?
This is not as common as Excel programming, but it might give some insight into their depth of understanding of the Project "database". Some folks automate look/feel issues, so printouts always look the same (consistency breeds familiarity). Other uses macros for particularly tricky utilization or costing calculations. The candidate should be able to glibly describe the benefits and challenges of automation with this tool.
I welcome comments / feedback on this list! If/when I get a decent number, I'll put together a nice little interview guide, suitable for download and re-use.
Previously ...
Technorati Tags:
best practice,
development,
documentation,
hands on,
interview,
ms project,
microsoft project,
project management,
tech management
Invisible Technorati Tags:
cazh1,
James P. MacLennan,
jpmacl,
MacLennan,
Labels: application development, design, documentation, microsoft project, ms project, PMO, tech management
When is a project a Project? How to prevent the buildup of backlogged requests
When is a project a Project? How to prevent the buildup of backlogged requests
I just wrote something up (internal wiki) that I thought was common knowledge, but I think it's one of those soft-skills things that makes total sense once you hear about it - but somebody needs to tell you.
I think of one of the reasons that IT (at times) intimidates the business - or why IT gets the cold shoulder when it comes to process improvement efforts - is that we can get a bit too wrapped up in the Art and Science of Project Management. It's hard to build that business-savvy image when every new idea that comes your way is met with a 12-month waterfall Gantt, a copy of the PMBOK, and a formal sign-off sheet.
Howzabout a little common sense first? When you hear about an interesting idea from someone in the business, spend some face time with the requestor. E-mails and phone calls will not suffice; you can't build a relationship that way. Have a conversation about what they want vs. what they need ...
- Sanity Check: Do they want something huge? Impossible? Impractical? is a great idea, but completely out of line with current corporate strategies/priorities? If so, help them understand they are boiling the ocean, it's overkill and/or not likely to get worked on in the next 12 months. If they agree that this is a bit of a stretch - hey, you're done! You've successfully stopped a bunch of needless administrivia work before it even started!
- If they still think it's a great idea, consider capturing the magic by putting together a simple (i.e. quick) Project Charter document, and adding it to your "master list" of projects. Then, immediately put the project on Hold. It will be in your database / list forever, we won't lose track of the Great Ideas embedded within ... but it will be off of our immediate radar screen.
- Training Issue: Are they asking for something that can be done in a different way (ie. shooting rabbits with a bazooka)? Maybe they don't understand all that (insert your favorite ERP here) has to offer. Can we solve their request with some training?
- Quick Hit: If they're asking for something that is twenty effort hours (or less), has minimal impact on a small number of people (ie. no training will be needed), and could get taken care of over a few days/weeks - consider it "filler work", and don't bother creating a formal Project for the effort. The business will love that you're delivering value without bureaucracy. Your brain will relish the chance to fill-in the dead time between meetings. And, your boss will/should dig it because it's lagniappe - that little something extra. Sometimes, all they need is a report tweak or a simple data download ... Web 2.0 is not the answer for everything.
- Caveat: Don't let this become the way that everything gets done. If a project is big enough, you should go through the proper level of rigor - it ensures that your efforts will be sustainable.
- The Real Thing: Ok, if you've made it this far - this idea is good, it's not too small, will involve a number of IT and business resources that need coordination and communication - i.e. Project Management - then yes, you need to follow your IT group's standard process. No shortcuts (from here on out ...)
Previously ...
- End-around the Prioritization Process (August 14, 2004)
- Pendulum swings - Santayana says ... (May 12, 2005)
- Finding shapes in the fog - How to frame a wispy, wandering conversation (September 7, 2005)
- Open Source as bargaining chip - driving business value of IT (October 30, 2005)
- Of course we can pay for that ... if it makes business sense (November 7, 2005)
- Answering questions with questions is a quick path towards irrelevance (December 4, 2005)
- The "Army Rangers" model for IT Professionals (January 2, 2006)
- No, you mean Smart as a Bag of Hammers ... (January 9, 2007)
- Continuing Education Pareto Principle (50/30/20) (February 13, 2007)
- Project Management Soft Skills Defined: Emotional Intelligence (October 17, 2007)
- Defining the Business Value of a Project (October 25, 2007)
- PMO Prioritization - Project Descriptions should be Effective, Relevant ... and Short! (December 9, 2007)
- How to Cheat at the PMO Prioritization Game (December 14, 2007)
- How to Win at the PMO Prioritization Game (December 18, 2007)
- Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
Technorati Tags:
business value of IT,
PMO,
project management,
Invisible Technorati Tags:
cazh1,
James P. MacLennan,
jpmacl,
MacLennan,
Labels: business value of IT, PMO, project management
Butting In to the Conversation: PM Communication Tools
Butting In to the Conversation: PM Communication Tools
Dennis McDonald and Lee White are conducting an interesting experiment on their blogs, crossposting a conversation about project management and social media. I'll add my voice, with both input on the topic and observations on the method.
(Topic) The Right Tool for The Job - depends on the Job
The first part of the conversation talks about whether social media could replace classic project management tools, in terms of communicating project status. I agree with Dennis - you can never get rid of gantt charts, project budgets, and stoplight issue lists. It really depends on who the recipient of this information is; most of my project sponsors are busy executives who rose to the top in the era of e-mail and PowerPoints. Communication is uni-directional - you to them. Team members and external consultants, on the other hand, require bi-directional, collaborative tools, and most expect web-based environments accessible in and out of the corporate network, instant messaging for quick status checks, and blogs for general updates.
Truth be told, the most valuable tools in the project manager's communication kit is typically Ctrl+C and Ctrl+V.
(Topic) The Perfect Tool for The Job in Unlikely - but Opportunity Knocks ...
Another one of McDonald's posts lists features a wish list of features for the perfect collaboration environment. It reads like a feature list for MS SharePoint, and McDonald anticipates the reaction well (I, for one, welcome our new Comment overlord ... )
I KNOW that many of these features are already available in off the shelf products. Comments that are thinly disguised sales pitches without a sincere effort to contribute to this discussion will be mercilessly and gleefully deleted.
It must be that time of year - I've gotten a number of calls from vendors in the last few weeks, pushing any number of PMO environments that promise to manage my resources and solve all my prioritization woes. In these times of tight IT budgets, capital investment for new software like this rare - the dollars are better spent supporting the business.
However, all is not lost. The collaboration requirements of most PMOs can be delivered quite nicely with a collection of FOSS tools, MS Office automation, and a little ingenuity. Looking for a low risk project to throw at aspiring web 2.0 technicians and Millennials suffering from wanderlust? How about those developers trying to learn what makes effective user interfaces?
Every PMO I've ever worked with / built up relied all or in part on locally developed tools; the cobbler's children can usually hack up something serviceable. And to borrow a phrase from Lee White - most of the skills for project management and collaboration comes from creating the tools, not having the tools.
(Method) Not the Right Tool for the Job
I'm not sure I fully understand the technology that Dennis has used to combine the text from these blogs, as well as everyone's comments. My first reaction on reviewing the feed was less than positive; like a typical blog feed, it probably puts the most recent entry first - so if you want to follow the conversation, you must jump to the end of the list and page backwards. Of course, once I dove into the content, I got a bit lost. I'm not exactly sure of the order of the items in the feed, but best I can tell, the conversation starts in the middle and then sort of bounces around.
Discussion forum software does better at this task. The start of the conversation appears first; as I move down the page, I can scan the main conversation thread as well as any branches from the comments.
That's the other challenge with this method of capturing and displaying a conversation. There are a number of interesting comments, but I can't figure out how to comment on the comment, nor can I figure out how to add another voice to the conversation.
I've written about this previously; the best tool for the job depends on the type of collaboration you are trying to initiate ...
- Use an Announcement to make a statement, inform of an event, where you expect no comments or replies. The flow of information is in one direction only - out from you to the readers of the web page.
- Use a Blog to make an observation, deliver a status update - capture a well-formed thought. One or two folks may have question or want to add a follow up, but in general you expect a few comments at most.
- Use a Discussion Forum when you are asking a question, making a proposal, or establishing a new standard. Here, we expect a lot of discourse, with threaded conversations and branches and such.
- Use a Wiki when you are making a statement / documenting a fact. You should expect refinements, additions, and other edits - but not full-on discussions.
Authors Note: I officially despise ecto at this time. This is the second time that I've written this post - spent an hour and a half on it last night, only to have ecto mysteriously delete my work. I'm switching back to w.bloggar for now - gave up on it a long time ago, but it appears to have gone through some pretty extensive improvements.
Previously ...
- Implementing Intranet on Speed: The Beginning (July 27, 2004)
- Communicating Complex Technical Concepts (March 21, 2005)
- Excellent series of posts for PMs communicating with non-techs (March 26, 2005)
- Blogs as Conversation, and Wikis as Diaries - Not Exactly (January 29, 2006)
- Guidelines for Success with your Skunk Works project (June 19, 2006)
- Documentation Redux - a Shorthand Proposal Framework, and the PMO Surprise (July 30, 2006)
- Project Status Dashboards Best Practice (and a PowerPoint trick) (May 3, 2007)
- Corporate Web 2.0 is Spreading - Here comes the Blog (May 15, 2007)
- What's the Difference between Announcements, Blogs, Discussions, Wikis? (June 26, 2007)
- More Challenges for Applying Web 2.0 inside the Firewall (July 2, 2007)
- Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
- The Right Web2.0 Tool for The Job (July 16, 2007)
- Communication is the responsibility of ... (August 19, 2007)
- Five Simple Rules for Project Names, plus Four Sample Lists (January 7, 2008)
- Update on Blogs as PM Tools - Tales from the Front Lines (January 20, 2008)
Technorati Tags:
collaboration,
PMO,
blog,
Project Management,
PowerPoint,
Web 2.0,
tech management
Labels: blog, PMO, presentations, project management, tech management, Web 2.0
Rules of Golf - Project Prioritization Process Needs Clear Documentation
Success, Failure, and Insights after 12 Months of Internal Web 2.0
Different areas of our IT department are using internal blogs, wikis, and collaboration spaces, with varying degrees of participation, readership, and success. Some observations:
Blogging is Easy ...
The blogs and wiki(s) have effectively removed the hassles of capturing and distributing information quickly. One important early decision was to not implement an editorial approval process for the wiki, and most blogs are wide open for public comments. No more excuses or complaints about a lack of documentation; if the explanation is not clear, or needs examples to make it relevant to multiple situations - all are fully empowered to fix it.
Some find the blog to be an easier way of communicating because of the "immediacy" - a sudden insight or pithy observation pops in your head, so you jump on the blog and capture the thought. These are the folks that have had a little insight, and gone beyond the idea of blogs as just an electronic replacement for a weekly status report. It might be difficult if you feel an obligation to say something every day - but if you really understand what you can and should be writing about, you'll probably make multiple entries every day.
... but Empathizing (with the reader) is Difficult
I still get pushback on the blogs - even among the groups that are currently our "best demonstrated practitioners". These folks are generating a decent amount of participation and content - but still not quite enough stuff to be effective. The challenge, it seems, is to get folks to empathize with the reader - a skill that I'm surprised more folks don't have, because many like to complain about what they don't know, or should know, or wish they knew.
Always ask yourself, what did I do or learn today that others would find interesting? No, it's not that the world wants to understand how my day went, or how I'm feeling. But I like to hear when people are starting (or stopping!) projects, or attending meetings and learning about events or decisions that may have an impact on my my work over the next three months. Empathize with your [potential] readers, anticipate their interest, and practice what I call the "beneficial assumption" ...
- Most people think the same way I do ...
- ... so I will anticipate what I'd like to hear about my organization, my projects, and my meetings ...
- ... and write about that
Self-Policing the Content
What about stuff that [possibly] doesn't belong in a blog - even though it's internal? Key thing is to use common sense; the blog entry is just as permanent, and much more public, than an e-mail. Especially when it comes to "negative events'; sometimes the specifics aren't really relevant and don't add much value. Specifics, like somebody made a fat-finger mistake and deleted some data, or opened a hole in the firewall, or copied the wrong file. A blog is typically not a root-cause, problem analysis tool ... it's a general FYI platform, and specifics (especially the negative ones) moght be taken out of context by the readers.
Of course, we note that content should not be limited to all that is sweetness and light. There's nothing wrong with fact-based bad news, but there's a lot wrong with bad news that no one finds out about and then gets worse, or no one learns from. We don't write about this stuff to get folks in trouble, but we definitely do it to prepare, inform and educate.
Communicating is Still an Art
Some folks will rattle on in too much detail, while others are too terse. The fundamental challenge - most folks can write acceptably, but may feel they can't write well - they lack the confidence to capture it on paper. Confidence is something that comes with practice, but mandating participation is not going to encourage spontaneous composition.
Where Are the Comments?
Some folks surprise themselves with a good blog entry, and then become doubly surprised when then get no comments. Bloggers in a closed community / internal blog can't judge themsleves based on numbers and responses that you mgiht see on the Internet - heck, it's taken me two years to get up to about 50 subscribers to my feed [feel free to subscribe, dear reader!].
Previously ...
- Heisenburg KM (July 13, 2004)
- I have nothing to say and I am saying it and that is poetry (April 6, 2005)
- Blogs as Conversation, and Wikis as Diaries - Not Exactly (January 29, 2006)
- The Law of Large Numbers - or, why Enterprise Wikis are Fundamentally Challenged (September 26, 2006)
- Do blogs fit in the enterprise? Specific examples (WIIFMs) ... (April 19, 2007)
- What's the Difference between Announcements, Blogs, Discussions, Wikis? (June 26, 2007)
- More Challenges for Applying Web 2.0 inside the Firewall (July 2, 2007)
- Driving Participation and Contributions on Internal Blogs and Wikis (July 7, 2007)
- Communication is the responsibility of ... (August 19, 2007)
- Update on Blogs as PM Tools - Tales from the Front Lines (January 20, 2008)
Technorati Tags:
blog,
collaboration,
Web 2.0,
wiki
Labels: PMO, presentations, project management, Web 2.0, wiki
Do you want it good or fast? Prioritizing Time-to-Value over Requirements
Do you want it good or fast? Prioritizing Time-to-Value over RequirementsI have a background in software product development, iterative "methodologies", and the sort of fast-twitch life cycle that characterizes entrepreneurial startups, high-growing businesses, and "lean" process improvement projects. Unfortunately, this style is also favored by departmental developer wannabes, sloppy coders, and impatient Gen-Y newbies that want to apply a consumer products mentality to corporate IT.
<aside>Yes, I'm throwing a bit of a challenge out with that last statement. I understand that as the demographics of my IT team changes, management style must change as well. However, notwithstanding CIO Magazine's recent deluge of articles urging oldies like me to "get with it", and embrace Web 2.0 flexibility, there are certain immutable facts that fly in the face of the recent college graduates urged to apply social networking, text messaging,
and torrent-enabled IP sharing to the 9-to-5 grind ... but I'll save that for a later post ... </aside>
The real challenge is understanding how to introduce this new and different way of thinking (about projects and project delivery) into an environment rooted in audits and controls, waterfall methodologies, and tightly integrated ERP. Nothing wrong with any of these - in fact, for work in and around your run-the-business systems, there's nothing more comforting than the rigor of requirements, testing, and a controlled promotion process.
Still, many organizations focus on the wrong legs of the Iron Triangle. Let's assume that budget, if not absolutely fixed, is at least severely constrained (again, we're not talking about a fast growth company that has money to burn). At this point, the typical IT department - laboring under the twin misconceptions that the customer is always right, and
the business understands the difference between wants and needs - dutifully captures all requirements, and work commences until there is nothing left to do. With budget and requirements "fixed", time is the variable, and projects go on for months.
I don't mean to sound cynical - sometimes it's not a question of kitchen sink requirements (as in, "everything but the ..."). Feature creep can also set in when folks want to develop code to test for every scenario or use-case. Even something as simple as adding type codes for a given transaction; believing in the power of metrics, folks will come up with a descriptor for every conceivable exception - regardless of the frequency or relevance.
I think the biggest difference between these organizations and their iterative brethren - startups, fast-growth, and "lean" organizations - is a focus on time to value. Established companies have predictable sales cycles, quarterly statements, and six month planning horizons; it's not about speed, it's about getting it right.
Established companies start to struggle with time to value when their environment changes. This is when a subtle change in project management style can go a long way towards liberating the locked-in value of these powerful organizations. Focus on that third leg of the triangle, and learn how to manage a project to a date. I have to be done in 60 days - what can I get done in that much time?
Sometimes this leads to a counterintuitive decision. For example, a make-to-stock company may have established a Microsoft standard for desktop systems, but a new line of custom engineered, make-to-order products may need to hire in a team of Macintosh-wielding product designers that must be productive on Day 1. In the long run, I may need to replace their new workstations, but I'm certainly not going to slow down the launch of a profitable new line while my standards team goes through a lengthy RFP and vetting
process.
Another common mistake - or maybe a defensive mechanism for those well-grounded in the status quo. Sometimes people “give up” on the idea of getting projects done in a short amount of time – “nothing happens quickly here”. I maintain that we give up on the idea of getting it done quickly, because we're not giving up on the demand for 100% requirements. If we insist that the work must be done in 60 days, we will have to give up some of the nice-to-haves.
This is the big change management challenge before us - prioritize time to value over requirements, and focus on the 20% of the work that will deliver 80% of the value.
Previously:
-
Customer Service, Roles and Responsibilities (September 25, 2004)
-
Things for the DIY programmer to consider (March 14, 2005)
-
Components, IT Responsiveness, and the Rosemont Horizon (June 22, 2005)
-
My Favorite Paradox (August 13, 2005)
-
Misapplying the Pareto principle (January 7, 2006)
-
War Stories from the Change Management front (August 21, 2006)
-
The Iron Triangle - Quality is a Feature that We Choose to Omit from Projects (October 28, 2006)
-
Search as the Killer KM App, and Good Writers will Rule the World (November 5, 2006)
-
There's a pony in here somewhere ... (January 1, 2007)
-
No, you mean Smart as a Bag of Hammers ... (January 9, 2007)
-
Another caveat for the erstwhile agile developer (January 15, 2007)
-
Defining an Effective IT Metrics Framework (January 21, 2007)
-
More on (sic) experience with wikis (January 31, 2007)
-
Continuing Education Pareto Principle (50/30/20) (February 13, 2007)
-
Excel vs. RDBMS: Choosing the Technology, Winning the Arguments (March 11, 2007)
-
Consarned whippersnappers (Generational Diversity) (May 20, 2007)
-
Five Key Skills for Successful Project Managers (June 18, 2007)
-
Tactics for Controlling Project Scope (January 5, 2008)
-
Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
Technorati Tags: business value, entrepreneur, Project Management, tech management
Labels: business value of IT, PMO, project management
