cazh1 » Project Management

Help for the Newly Minted Project Manager

Jim MacLennan — Tue, 22 Nov 2011 02:25:45 +0000

Go-Live Day

Congratulations! Due to the recent [acquisition / divestiture, market expansion / contraction, organizational realignments, other] you have been identified as a Critical Resource for this particular bit of business process change. And, to help us implement these changes, you have been named the Project Manager for this effort.

So now you are a Project Manager (PM, for short); what does that mean?

You may be vaguely aware that people get certifications for this sort of thing, or that Microsoft sells some Fairly Expensive Yet Sophisticated Software that helps create Can’t charts (or something like that).

You may also have this slowly growing sense of unease, as it becomes apparent that Project work is something that many folks don’t like to do – because being part of a Project Team represents an interruption to their already fully scheduled lives, with Tasks that will [by definition] someday End (… and where will that leave me?)

Don’t Panic

Every day, people in Operational areas of their companies get appointed to be “project lead” or project manager, but have had little training in formal Project Management. More often than not, however, the Project in question is of reasonable size (maybe 2-3 months in duration, with < 10 people on the team, and goals and objectives that are achievable “with stretch” (’cause if it was a no-brainer, we wouldn’t need to name you Project Manager, n’est-ce pas?). So relax for a bit, and let’s go through a little “crash course” in some of the basics of Project Management.

You may note, by the way, that much of PM may seem like simple ideas and common sense; this is true, and that’s a good thing to note – you’re calming down already.

Over time, you will learn that these simple ideas can be decomposed in many intricate bits; I wasn’t kidding about all that Certification stuff – as projects add people, systems, time and budget constraints, and shifting requirements, and you will understand why people talk about training and skills and battle scars …

Sorry, didn’t mean to lapse into that same old line of intimidating line of thinking … let’s just start with the basics.

What are we working on, and why are we working on it?

The new PM can be surprisingly effective with some fairly basic bits of information – clarity and reasonable precision go a long way when guiding a new team through a set of tasks that they aren’t used to doing every single day.

Clearly state the objectives of the project – what are we trying to accomplish?
What are the specific requirements? What are we building / implementing to deliver the objectives?

Are there a specific set of features, functions, documents, new skills, new services, process addition/changes, etc. that need to be delivered?
Any expectation of quality? Can this be slap-dashed together or must it meet the building code?
Any time constraints? Is there any sort of must-have-by date, or can it slip a little bit (to get more features or better quality?

Capture the benefits – what are we getting for this?

Identify total costs (hard and soft, let’s not forget the time we are spending in addition to our regular jobs)

Define success – how will we know we are done?

Note that Objectives are different than Requirements. I am trying to “deliver better customer service by delivering more accurate information on the invoice” (my objective). I will do that by “adding information to the customer orders, and printing it on the hard-copy invoices” (my requirements).

How are we going to get this done?

This is the most important, yet most often overlooked bit of PM work – you need to lay out the steps that need to get done, and who will do the work. Be careful – this is where many newly minted PMs get lost in the minutiae or intimidated by the details and intricacies – and folks often make mistakes in two different directions …

Too much detail – bad, because the PM overhead becomes daunting, or the project work suffers from analysis paralysis and never gets started
Too little detail – bad, because team members don’t fully understand dependencies, skip over key requirements, or underestimate work time

Keep it simple to start – you don’t need any fancy software or tools – a simple notepad will do. Just lay out the tasks required to get the work done, in sufficient detail such that you can reasonably gauge the total time required, and see where each of the major requirements will get covered.

You will also want to identify resources – people – who will do the actual work. Don’t talk in terms of “roles” or any fancy euphemisms – put actual names against each and every task. In addition, you’ll need to estimate how much time it will take to get each tasks done – you’ll have to add it all up, to check that it can all get done by any date you may have targeted for completion (ok, so maybe a spreadsheet would be a better tool than a simple notepad …)

Should we be working on this at all?

After laying out the tasks, you may find yourself going back to the total costs and/or the original estimated schedule with updates – and don’t be surprised if the time and costs increase, most people seem to estimate projects optimistically in the early stages. However, as your understanding of the total cost to deliver these requirements improves, it’s always fair to go back and validate if you should be working on this project in the first place – does it still make sense to go after the stated benefits if I know it will cost this much now?

The Most Important Thing

By far, the most critical responsibility for the PM is communication – you’ll want to plan and execute all of your project updates and track all project information as comprehensively as possible.

Keep participants and sponsors aware of status – progress updates, major issues, coming milestones, etc.
Track “planned work” (tasks) and “unplanned work” (issues)
Capture knowledge – about new processes, assumptions, technical details, etc.

Remember, Rule Number One for project managers is Manage Expectations; most executives will tell you that they can handle disappointments when given enough lead time, but last-minute surprises are Bad, but magnified to Horrible with the lens of No Lead time To react.

A Nice Start – Now What?

Yes, you are right, there is much more detail to drill into on the Art and Science of Project Management. But let’s not forget that projects have been going on at your company for years – let’s not reinvent any wheels here …

Does your organization have any standards or precedents in the functional area that you are working in?
Is there a formal / informal, or traditional project methodology?
Are there any existing communication requirements / expectations / traditions?
Any available collaboration spaces, like SharePoint?
Any available tools – for PM, for Training, for Knowedge Capture?
Any available templates – for standardization, but also for short-cutting your work?

And remember, everyone else is happy they didn’t get picked to be Project Manager, so you don’t have to worry about competition …

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | One comment |
Post tags: benefit, budget, business benefits, cost, critical resource, Gantt, managing change, managing expectations, managing projects, MS Project, MS SharePoint, project charter, Project Management, project manager, project planning, Requirements

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Idle Time is a Good Thing for IT

Jim MacLennan — Mon, 21 Mar 2011 01:28:22 +0000

... given the right circumstances ...

Lots of good conversations recently about managing IT, Finance, and other constrained resources for projects. We have implemented tools to model available time; when trying to understand what new work can get added to the pile, it helps immeasurably when you understand how much time you have available, plus what else has been committed.

This has become a powerful process for managing chronically constrained resources – but one side effect is that other folks on the team can find themselves less-than-fully-committed. Note that I don’t say available or loaded with free time – most will readily agree that there is always something to work on. The trick is finding the right thing to work on.

I am reminded of something I read about in Goldratt’s The Goal; among other things, it observes that when optimizing a production line, it’s entirely probable that we will be underutilizing one or more workstations. If we optimize every workstation (point optimization), we will be building up inventory, and generating waste. For people on our IT team, “building inventory” means working on stuff that is of low priority, or creating new projects or tasks that are on someone else’s To-Do list – things that they just can’t get to.

These folks must go on idle – they have some free time! Unfortunately, it’s very hard for most people to allow themselves to actually be idle, or even appear underutilized (… if I’m not working like crazy, they’ll think I’m not adding value …).

Of course, time is precious, and you don’t really want to be burning idle time. This “common sense” approach has a name – Productive Use of Free Time, or PUFT – and for enlightened IT teams, it’s an excellent opportunity to invest in themselves and their processes:

investing time learning new technologies (self-directed study)
structured cross-training to understand other technologies, especially for those areas that are constrained
root-cause analysis to stomp out nagging bugs
process automation to make those repetitive tasks a tad less monotonous
process documentation to capture and transfer knowledge, and make systems & processes easier to support

Caveat: Work generated to fill in this time can sometimes become a “priority” for folks, who feel they simply must finish things before they can get back to their high-priority project work. I think that some people just don’t like to leave things undone, work-in-process to come back to them later. This PUFT approach adds real value when you can leave things undone for a bit, and pick them up when you have time – it also teaches you to document things as you go, so you can effectively pick things back up again.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | No comment |
Post tags: cross training, free time, Goldratt, point optimization, process documentation, resource management, resource optimization, resource scheduling, Theory of Constraints

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Estimating Bird-Dogging Time for Project Tasks

Jim MacLennan — Mon, 10 Jan 2011 01:18:41 +0000

Click for the original ...

New year, new projects, and new adventures in getting folks to think in project management terms. I’ve written before about Calendar time vs. Effort time, but this past week we came up with a new distinction that is worthwhile to call out.

When working with the business and getting folks to estimate how much time it will take to complete a task, there are actually three different things that most people will talk about – and folks need to be clear on what we’re asking for:

Effort Time – The amount of actual working time it takes to get something done. This is typically a reasonably small number.

If I could work straight through, and get the answers I need from everyone involved, I would probably spend about 8 hours typing this report up …

Calendar Time – Of course, it is rare that folks from any business can work on project tasks uninterrupted. Typically, we’re planning 20-30% availability, so we know it will take about a week to get this task done – normal delays, time gaps really, that should be somewhat predictable.

… but I do have my ‘real job’, you know – I’ll get this to you by the end of the week …

No surprises to this point – but you must be clear when asking for time estimates during project planning. Are you going to go by Effort Time, and allow the resource availability settings tell you when you can expect a completion? Or are you asking for Calendar Time, and skipping the fancy stuff?

However – when getting calendar time estimates from folks, make sure you understand why something will take so long. Some folks, burned by past dependencies on recalcitrant contributors, will pad their estimates with Bird-Dogging Time …

… or maybe the week after – I have to chase down this information from a number of people.

Again, this is all quite natural and normal in most organizations; but you need to make sure everyone estimates and reports tasks and durations consistently.

It will take 1 month per system to set up a data feed with the customer? Are you kidding me here?

Calm down – that is most likely a Calendar time estimate, factoring in delays due to “negotiating” process and structure with the trading partner. Rest assured, plenty of other project work will be going on while the technical details get worked out. Just make sure folks understand your qualifiers, and that all tasks in the project plan are estimated somewhat consistently.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2011. | Permalink | No comment |
Post tags: calendar time, effort time, Gantt, MS Project, Project Management, project planning, time estimates

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

The Magic In the Middle

Jim MacLennan — Mon, 26 Jul 2010 02:58:49 +0000

I don’t know where I first heard that phrase, or what it originally meant, but I have been using it a lot in the last few weeks …

Consider the entire user population for any web site or application. You can generalize all user populations into three Pareto-inspired groups …

Top 20% – The folks who “get it”, and have the brains, the interest, and the desire to fully understand the system / tool / report / whatever, and get the most benefit out of it. In Pareto terms, the 20% that get 80% of the value.
Bottom 20% – The “hopeless”; those that just don’t get the concept (and need constant handholding), have no interest in using the app (at best, they will have someone do it for them), and no desire to expand their horizons and learn something new. In Pareto terms, the 20% that cause 80% of the problems.
Middle 60% – aka “everybody else”. This is the group of users that could get value out of the project, process / program, but need more handholding, guided learning, and/or managerial promises (/threats) to commit to learning how to use and apply this new tool.

Click for the original ...

I call this last group “the magic in the middle”; this is the user group you need to win over to ensure success for the project. In corporate IT, most projects would be considered a failure if they only got 20% of their target audience to realize the promised value – then again, no one expects 100% success, especially with the bottom 20% of folks that will Just Never Get It. So, the make or break “target market” for training and retention is the “magic in the middle” – the folks who need a reasonable level of documentation and training to get things to work.

Note that “magic” refers to the fact that what really differentiates success – that core region of 60% – is the make-or-break group that takes the extra effort. It’s not good enough that your top finance folks understand the new reporting and analytics system – the middling folks that need more handholding and examples are the ones you need to focus on. It’s not good enough that your top project managers understand the new methodology – the journeyman PMs that have more tech background than change management and communication skills need guidance and templates and checklists to make sure the minimal I’s are dotted and T’s are crossed.

Interesting Observation …

This is one of the core reasons why analogies between corporate IT and consumer IT often fail. How many times have people in the business asked IT for projects as flexible, ubiquitous, user friendly, and high quality as Flickr, Basecamp, and gMail? Or tried to address internal communication and collaboration challenges with tools like Facebook, Twitter, and Google Groups? Why do folks look at highly target-marketed sites / communities of practice, and cynically wonder why internal IT can’t turn over project requests with the same level of speed and quality?

One key reason – those sites only need to go after the Top 5% group of focused, engaged, and technically able potential consumers – because the internet is so big, there is plenty of money to be made from such a small percentage of the total user population. Unfortunately for corporate IT, it is not OK to implement systems that are effective only for 20% of the target user community – expectations are more like 50-80% of the user population needs to be reasonably glib in the system to be judged effective.

… but What Does It Mean?

Corporate IT is forced to go after the “middle” group – the 60 percent of the user base who needs a lot more TLC to understand and be effective in the tools and systems we provide.

However, I call it “magic” for a reason. You can leverage a lot of value once you realize that “the magic is in the middle”:

Training: When you understand the low-end expectations for end-user competence, you can target your training material at that level – and no lower.
Testing for 100% of all cases is exhausting and time consuming, a real drain on resources. However, only testing the basics (the Top 20%) won’t require a lot of rigor, for the error checks are simplistic and the level of scrutiny is much higher. If you want to do an acceptable amount of decent quality testing, your test cases should involve “the magic in the middle”.
Vendors: Bringing them in for a demo? Salesmen typically target business scenarios that are the “low hanging fruit” (in the Top 20%), and it’s easy to understand when the software can’t handle the “worst case scenario” (the Bottom 20%); get the sales team to demo something from “a typical Day In the Life” (the Middle 60%)

The Top 20% group is the easiest to service, the Bottom 20% is the easiest to ignore. The magic is in the middle, and success here separates the excellent from the also-rans in corporate IT.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010. | Permalink | No comment |
Post tags: cognition, education, Facebook, Google, LinkedIn, Social Networks, Twitter

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Defining Business Benefits: Hard and Soft

Jim MacLennan — Wed, 07 Jul 2010 03:09:27 +0000

All projects should have a clear objective, a practical plan,
and an understanding of the costs and benefits to get the thing done.

Easy to say, but a lot of project teams struggle to crisply and clearly define specific business benefits. One way to move the process forward would be to have a clear understanding of the types of business benefits you might claim.

Hard benefits come from firm commitments to make measurable differences in the amount of revenue generated or savings realized. When claiming hard benefits, the business manager will actually increase their revenue budget (or reduce their expense budget) because of the impact of this project.

Real, measurable “Top Line”: volume / revenue growth
- “I will be able to sell 10% more …”
- “Market share will grow 2% …”
- “This new product line will generate 5MM pounds incremental sales …”

Real, measurable “Bottom Line”: cost reduction, FTE reduction (people)
- “I will cut 10% of my use of electricity …”
- “I will eliminate two FTEs [positions] …”

Your guess is as good as mine ...

Soft benefits come from the strong belief of the business manager that the benefits will be there – but they may be hesitant to make changes to their budget. The hesitation may be there because there is some risk of attaining the benefits from other factors; or, the savings are based on unsubstantiated estimates (i.e. “educated guesses”, aka onager heuristics). When claiming soft benefits, the business manager may not necessarily increase their revenue budget (or reduce their expense budget), hedging against other factors.

An important type of soft benefits is Cost Avoidance; a project that automates a manual process could allow the company to increase the number of transactions processed without adding incremental headcount. You haven’t reduced the operating budget, but you have enabled more productivity without additional cost – this is cost avoidance, and it is an important soft benefit.

Benefits that are subject to risk could be dealt with by making them soft benefits; if the manager is confident of the magnitude of the savings (”… this will cut 20% off the cost …”) but not of the likelihood of the savings (”… if everything goes our way …”), then you should call the total amount a soft benefit.

Anticipated “Top Line”: volume / revenue growth
- “I will be able to sell 10% more, as long as …”
- “Market share should grow …”
- “This new product line gives us a leg up on 5MM pounds incremental sales …”

Anticipated “Bottom Line”: cost reduction, FTE reduction (people)
- “I will cut 10% of my use of electricity …”
- “I will eliminate two FTEs [positions] …”

Anticipated “Bottom Line”: cost avoidance
- “… this will allow me to process three times the volume …”
- “… this will eliminate downtime …”

Productivity – Many systems projects involve automating manual processes and/or streamlining overly complex processes. Productivity is increased when it takes less time for fewer people to generate more work and more results.

Productivity benefits are quantified as a reduction in the total number of effort-hours per month required to perform a task. We often speak in terms of full time equivalents, or FTEs; to keep the math simple, one FTE is about 2000 hours of work per year.

Productivity is a soft benefit because we do not always remove people from the work force when implementing productivity improvements. Typically, the aim of any automation is to free people up to do other process management or analytical tasks. Note, however, that you can turn productivity into a hard benefit by reducing either overtime or headcount.

Note also that it is difficult to establish a common and fair hourly rate for a worker, due to many factors (including job type and geographical wage rates). For this reason, it is sufficient to express productivity in terms of labor hours saved.

Next: Marching down the P&L and the Balance Sheet

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2010. | Permalink | No comment |
Post tags: budget, business benefits, cost, cost avoidance, finance, Productivity, revenue budget, total cost of ownership

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

The Delicate Art of Pushing Back

Jim MacLennan — Sun, 05 Jul 2009 23:33:00 +0000

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.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | No comment |
Post tags: communication style, contractor, emotional intelligence, empathy, project manager, Requirements

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Over / Under Communication for Project Managers

Jim MacLennan — Tue, 30 Jun 2009 01:16:00 +0000

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.

Media

To 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.

Translations

You 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 Management

Volumes 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 Learned

As 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.

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | 2 comments |
Post tags: Change Management, Communication, Dennis McDonald, Project Management, SAP, SAPanese, slang, sound bite, terminology

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Location, Location, Location: Terminology Confusion in ERP Projects

Jim MacLennan — Sun, 12 Apr 2009 00:12:00 +0000

Have you ever experienced the clash of terminology that results when supply chains are brought together, due to acquisition or merger? The typical scenario: different groups using multiple terms to describe where product is manufactured at and shipped from; folks use terms like “location”, “plant”, and “site” interchangeably, and confusion can result – are we talking about SAP configuration? Wide-area network architecture? Rollout plans?

To communicate effectively, it helps to clarify things. Here is a starter list of terms from projects I’ve been involved with. Care to add / edit the list?

Generic Terms

A building is what it sounds like – four walls and a roof.
A facility could refer to one or more buildings.
A campus is a generic term for a group of buildings.

Specific Terms – ERP

In SAP, a Plant is a place where materials are produced, or goods and services are provided. A Plant is made up of one or more buildings.
In some Warehouse Management Systems (WMS), a Warehouse refers to a single building. In SAP, a Warehouse is a collection of Storage Areas; a building can contain multiple storage areas, and a warehouse can span multiple buildings.

Specific Terms – WAN

A Site typically designates a point-of-presence to the Wide Area Network (WAN) – a cluster of WAN devices that connects one or more buildings to the network.

Details!

A Chinese proverb states, “Wisdom begins with calling things by their right names.” When bringing companies and cultures together, project managers need to pay special attention to the words; we must be very precise with our language, so everyone understands that we are all talking about the same thing.

Previously …

Excellent series of posts for PMs communicating with non-techs (March 26, 2005)
Bug bad, bug good, bug Bug (May 18, 2005)
Need to watch my terminology (August 16, 2005)
Thoughts on Why Tech Folks Hate Documentation (July 8, 2006)
Communication is the responsibility of … (August 19, 2007)
The Five Fundamental Rules of Project Management (October 15, 2007)

Technorati Tags: best practice, documentation, Knowledge Management, project management, SAP, supply chain

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2009. | Permalink | One comment |
Post tags:

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

Dueling Collaboration Portals

Jim MacLennan — Mon, 24 Nov 2008 02:17:00 +0000

I noticed an interesting phenomenon this afternoon; we are experimenting with SharePoint as our internal project management / collaboration portal. A nice platform to choose, because it’s popularity is growing, and there are a wide selection of add-on products and development partners ready, willing, and able to help us spend our money to make it even better.

The interesting part is that we are running into other companies who are also working with SharePoint. Specifically, third-party consulting firms that want to work with us on projects – they have (wisely) set up outward-facing portals, so they can effectively connect and collaborate with the paying customers.

Basic training is clearly not an issue here – but after a few hours, some of the (ah, what’s that word? oh yes …) interesting issues come bubbling up …

Mechanics

What’s the protocol here? An internal project could start their own team site, and when the external partner is selected, we’ll want to pull them into our collabora-party. Intuitively obvious, but most end-user firms do not regularly extend their intranet / SharePoint servers outside the firewall.

Of course, your external partner may be righteously convinced of the superiority of their portal-enabled project management process – leaving us with a new type of distributed version control problem. Even if we manually keep document libraries in sync – I’m to lazy to deal with dual entry of issues.

Intellectual Property

There may be an IP assumption that needs some clarity. I’d wager both parties have a certain interest in any intellectual property generated during the engagement – will this portal approach make it easier or more difficult to control? And what about the IP represented by the blogs, wikis, discussions, etc. embedded within – will the end of the project deliver an electronic version of all that stuff? You may need to revisit your Master Consulting Agreements.

Interoperability

Data sharing is straightfroward when both organizations are running SharePoint. It becomes problematic if different portal platforms are used. I’m currently not aware of any standard workflow or portal object API – possibly another great opportunity for some entrepreneur – portal synchronization over the Internet?

In Retrospect

None of these general concerns should surprise – it’s just the latest iteration of a common problem when dealing with electronic meda. We’ve all seen engagements where organizations are on different e-mail systems, different versions of MS Office – even different platforms (Macintosh vs Windows, AutoCAD versus Pro-E). I’m sure more are on the way – Dokuwiki vs. MediaWiki? Et 2.0, Brute?

Previously …

Strategies for Fee Structures in Consulting Engagements (March 5, 2006)
Strategies for Intellectual Property in Consulting Engagements (May 8, 2006)
Strategies for Risk Sharing in Consulting Engagements (May 12, 2006)
Strategies for Malware in Consulting Engagements (May 28, 2006)
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)
Innovation That Matters – Substance Over Style (January 12, 2008)

Technorati Tags: best practice, collaboration, innovation, Knowledge Management, PMO, project management, Web 2.0, wiki,

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2008. | Permalink | No comment |
Post tags:

All articles, blog entries, and other content on this site are licensed under a Creative Commons License

MS Project, Early and Often

Jim MacLennan — Sun, 09 Nov 2008 04:47:00 +0000

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

Click to enlarge ...

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 …

Questions? Comments? Suggestions? Send mail to webmaster at cazh1 dot com
© Jim MacLennan for cazh1, 2008. | Permalink | One comment |
Post tags: agile, Gantt, Lean, level resources, managing projects, MS Project, planning, Project Management, project manager, Requirements, resource assignments, visual, waterfall

All articles, blog entries, and other content on this site are licensed under a Creative Commons License