Based on your experience, what is the best business to start within 12 months and why?

If you could suggest a business to start soon, highly profitable, in a growing market, but with little need of capital, what would be your best guess? What would be the strategic assets needed for success?

Guido Sullam

Business expert

Wow. That’s a pretty open question. A lot would depend on the amount of capital that you have available (“little” is a relative term), your network, your tolerance for risk, your own personal expertise and interest and what you consider to be “a business” (are you trying to build an empire or personal wealth?)

For example; If you’re a skilled technology or business professional with a good network of peers and potential customers, You might want to consider starting a consulting company. The startup costs are minimal, potential profits are high and your knowledge and expertise would be the key assets. It would primarily be a case of marketing your services and lining up customers. (don’t forget that you could also partner with someone who has that network and would be willing to work it for you.)

Franchises are a mixed blessing. You’ll need to do your due diligence to understand the business and the market that you intent to enter. More responsible franchisors will insist that you do this by default. But the less professional ones will just take your cheque and let you deal with it.

MLMs are an easy way to some quick money if you have the hustle and a decent network. However, you’ll burn at least some of your contacts. I would avoid these. I only mention them before someone else does. I know some people that swear by MLMs, but they’ve always rubbed me the wrong way.

Direct services business are hot right now and a good investment. Daycare, medical, store-front retail, food services, cleaning, entertainment, etc.

Real Estate may be a good investment in the longer term, but requires access to capital and a certain amount of expertise to pick the right deals. It’s a buyer’s market right now with a lot of good deals. But there are no gaurantees that there won’t be an additional drop before the rebound. So you would need enough capital to be able to keep your investments afloat.
There are a lot of opportunities for commercial development as well. But, again, you’d need the expertise and network to leverage those oppoprtunities. Don’t ignore the ability to leverage a small amount of capital to control a relatively large investment.

My recommendation to you would be to make a list of your skills, hobbies, interests and assets and then start brainstorming where they might be a good fit. You may find that something jumps out at you.

Once you have a list of potential opportunities, assess the risk, reward, “fun level” and document all of the things that could possibly go wrong and how your would deal with them.

If your interest is simply in the financial transaction, you might want to consider brokering deals for other entrepreneurs or groups. Your profile indicates that you may have the expertise to do this. A bit of focused research and a LOT of networking could provide you with that “low capital/high profit” opportunity.

Do you follow any best practices for conducting effective virtual meetings (i.e. conference calls, video conferencing, WebEx, etc.)? If so, what are the top two or three that come to mind?

If you do not have a set of best practices to share, what about pet peeves related to virtual meetings…?

Tom Nieman, RPA, ARPC, CMFC

Relationship Manager at New York Life Retirement Plan Services

I would recommend a lot of the same best practices for physical meetings:

• Publish an agenda before the meeting stating expected outputs from the meeting
• Invite the people that need to be there and if there’s any doubt or confusion around why someone is invited, send them a private note explaining what you expect of them (eg. “I thought that you may have some valuable insight into xxx and I’d appreciate it if you could attend”)
• -Take a roll call with job function or group that the represent. Keep the list of participants and roles in front of the presenter
• Establish and state the ground rules for the meeting up-front.
• This is a tough one for a lot of people – *Don’t* recap the meeting for latecomers. Offer to fill them in on a break or at the end of the meeting, but don’t allow one or two people to derail everyone else.
• Stay focused on the agenda and reign in anyone that takes the meeting off on a tangent.
• Have someone *other than the presenter* take notes
• Actively poll the attendees rather than relying on general callouts like “Any questions? Any Issues?”. Before breaks just go through the list and ask each person by name if they have any questions.
• Find opportunities to ask relevant questions of specific individuals. It will keep the rest of your audience focused. (eg: “Tom…this section of the presentation covered issues that I thought you might see in Sales…are there any specific opportunities that you see?”)
• If you have large groups that make verbal polling impractical, make use of online realtime surveys, virtual “show of hands” by requesting participants to change status, etc.
• Don’t dawdle. State your point and move on. People multitask in virtual meetings and you’ll need to keep things moving to keep the group focused.
• Summarize points and discussions as you close each section of the meeting (also a good way to confirm your minutes)
• Try to leave time at the end of the meeting to evaluate the effectiveness of the meeting with the participants.
• Start and finish on-time.
• Publish minutes in a timely manner (no more than a week after the meeting. Preferably the same day.)

Check out any guides to effective meetings and just keep in mind that you don’t have the ability to read body language and there’s no deterrent to people multitasking during the meeting.

What’s the *real* difference between Program and Project management?

One of my colleagues was in your PMO roundtable earlier this month and suggested that you might be able to provide some insight. I’m getting pressured to move from Project to Program Management, but I don’t really understand the difference. I already manage multiple projects and it doesn’t seem like our Program Managers do anything different. I know that we don’t always have the same view of job roles and titles that the rest of the world does. What should a Program Manager do and how are they different?

Name withheld – via email

There’s a lot of confusion around Project, Program, Project Portfolio and IT Portfolio management. The terms get tossed around loosely and they’re often (incorrectly) thrown together as part of a single career path. This leads to a lot of confusion as people get “promoted” into jobs that they aren’t equipped to handle. This leads to frustration, ineffective PMOs and a bad rep for the various disciplines.

Let’s start at the beginning. Bear with me. You probably know a lot of this already, but it helps to build this from the bottom up.

A “Project”, according to PMI, is “a temporary endeavor undertaken to create a unique product or service.”  This definition leads to a lot of work efforts being called “projects” when they really don’t warrant formal project management oversight or aren’t defined well enough to treat them as projects. I prefer my own definition:

“A Project is a scoped work effort with clearly defined acceptance/exit criteria, budget and schedule.”

This gives you the holy trinity of Quality, Cost and Time and prevents the expectation that a PM should manage undefined and unscoped work as a project. If you don’t have a clear idea of what your deliverables/goals are, you simply don’t have a project. This doesn’t mean that you have to know the minute details up-front. But, you do need a clear agreement of what your customer expects and what success looks like. The requirements, budget and schedule may evolve as the project progresses. But, you need some sort of starting point to manage the work as a project. The difference in the definition of “Project” doesn’t really impact the rest of these definitions, but it’s a bit of a pet peeve of mine.

PMI’s definition of a “Program” is “a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually”. This is a good theoretical definition, but can be a bit vague for people looking for practical guidance. The most common use of Program Management is to manage projects that have dependencies between them. Shared deliverables, risks, predecessor/successor tasks or even shared resources or assets need to be coordinated between interdependent projects. It’s the responsibility of the Program Manager to ensure that projects supporting common or related business goals are kept in sync and don’t end up in conflict. Individual Projects have a responsibility to their stakeholders. Program Management ensures that those stakeholder needs are balanced with realizing the common business benefits. A program may be temporary or may be perpetual (eg: a Program may be formed to address a new regulatory issue or an acquisition. In these cases, the Program would likely close out when the goal was acheived. A Program may also be formed around an ongoing function like Marketing or supporting a specific customer. In these examples, the component projects would be temporary, but the program would be continually updated with new demand or projects.)

For our final PMI reference, a “Project Portfolio” is “a collection of projects and/or programs and other work that are grouped together to facilitate the effective management of that work to meet strategic business objectives”. These objectives may be the support of a particular business unit or function, a common budget or a specific pool of talent or resources. More simply stated, a ‘Portfolio’ is the collection of all demand that needs to be balanced against limited resources. The “management” of the work is usually limited to grouping, organizing and prioritizing your demand to ensure that you get the optimal value out of finite resources. This includes a certain amount of project and program oversight  (not management) to identify risk, potential benefits realization and resource issues in order to continually reassess and optimize the Portfolio.

The “IT Portfolio” is the collection of projects, infrastructure, people, applications and knowledge assets (including data and processes) of the IT organization. IT Portfolio Management usually includes the IT Project Portfolio Management function, but it also encompasses all of the assets that may be impacted by or created as a part of these projects. Due to the nature of IT projects, the infrastructure and asset management of IT is closely tied to IT projects through the IT and Project Change Control and Change Management functions. I’m not going to go into any depth on IT Portfolio management. I only bring it up because there’s often confusion around “IT Porfolio Management” and “Project Portfolio Management” in IT groups. For more detailed discussion, check out ITIL (the IT Infrastructure Library) and ISACA’s CobIT (Control Objectives for IT)

With those basic definitions out of the way, I’ll move on to the roles. For each role, I’ve indicated where they fit into the *enterprise* view. Keep in mind that this view changes as the perspective changes. What may be an “Operational” function from the Enterprise perspective becomes “Strategic” to the person responsible for that function.

Task/Work managers
Operational
Key Phrase: “Get the job done”

The primary job skill here is an intimate knowledge of the technology, business or area where the work is being performed. The Work Manager needs to have the ability to manage time, estimate work and react to changing situations is key. In many cases, the people managing the work are also the ones performing it.  A “lead” can mentor other people in the team and develop or supply these skills where they’re lacking in other team members. The focus is on simply performing the work. When a project is poorly scoped or defined, “Project Managers” can easily fall into the reactive mode of functioning as “Work Managers”. Instead of managing the project, they end up managing the people and the work.

Staff Managers
Tactical
Key Phrase: “Develop Talent”

The primary job skill is managing people. The Staff Manager needs to have the ability to manage conflict, identify individual strengths and weaknesses and to get the maximum value out of each staff member. The focus is developing existing resources and ensuring that their staff is able to address current and future needs. They’re an escalation point for issues with work management, but their primary focus in on ensuring that the relationship between the company and the individual provides the maximum mutual benefit.

Project Managers
Operational 
Key Phrase: “Deliver the project”

The primary job skills are change control and risk management. The Project Manager needs to evaluate proposed changes to determine the impact/value to the overall project, appropriate course of action, escalation and renegotiation. The Project Manager needs to have the ability to perceive and mitigate risk, intelligently apply and manage defined project management processes and to maintain the alignment of team members to deliver on commitments. These commitments include the specified deliverables with the appropriate level of quality using the agreed-to schedule and budget. The primary focus and responsibility of the project manager is to the health and success of the project. All other skills and responsibilities are in support of this focus.

Program Manager
Tactical 
Key Phrase: “Deliver Business Outcomes”

The primary job skills of a Program Manager are change management, communication and negotiation. The Program Manager needs to ensure that related and interdependent projects are coordinated to deliver the expected business outcomes. Changes in individual projects need to be understood and the expectations and needs of the related projects may need to be renegotiated. The primary focus is not on the specific deliverables of the component projects, but on the overall delivery of value to the business. Project Managers are accountable to the individual Project Sponsors and are focused on delivering the optimal value for that sponsor. A Program Manager is responsible for maintaining balance between the projects within the program to deliver value for the Program sponsor or the business as a whole.

Project Portfolio Manager
Strategic
Key Phrase: “Maximize Strategic Value”

The primary job skills of a Portfolio Manager are Strategic Planning and Benefits Realization. The Portfolio Manager needs to optimize scarce resources (financial resources, people, skillsets, assets, etc.) to optimize the value of the project portfolio to the business. Existing projects and new demand need to be continually balanced to ensure the highest possible benefit realization. The Portfolio Manager needs to negotiate and renegotiate the prioritization of projects and resources in the context of the overall business strategy. Challenges to Programs and Projects need to be considered in the context of the overall portfolio and resources may need to be reallocated across programs/projects to maximize business value. The focus and responsibility of the Portfolio manager is to get the maximum strategic business value out of a constrained pool of resources.

As you can see, these are very different functions and skillsets. While there’s considerable benefit in having experience in the connected disciplines, they aren’t part of a continuous career path. A Project Manager may develop the skills to be a good Program or Portfolio Manager, but that’s not a given. An Engineer may develop strong finance skills and become a CFO. Those engineering skills may provide insight and understanding that would be complementary to controlling the finances of an Engineering organization. But, CFO is not a logical progression from Engineer. Similarly, being a good Project Manager will provide insight that’s valuable to a Program or Portfolio manager, but it’s not a requirement or an indicator of future success in the role.

With all of that said, Project Managers in most organizations end up developing a broad range of skills in order to survive. We end up working as analysts, change managers, financial reporting staff, HR, strategic planners, trainers, etc. If you’ve exercised your Change Control, Risk Management and Negotiation skills, you may be in a position to be a strong Program Manager. That has very little to do with your formal Project Management career path and everything to do with your own personal experiences. I know some excellent PMs that simply aren’t wired for Program management. I also know some people that are phenomenal Program Managers who’ve never managed a project.

I hope that this helps.

The  Community Roundtable that I was asked to run at Symposium ended up “Going Stealth” this year due to approval issues and sign-offs from legal (the usual corporate BS). However, we did end up having the session in an unadvertised back corner of the Yacht & Beach club. I’d like to thank everyone who participated. Hopefully we can be a little more “above board” next year.

Here are some of the takeaways:

Roundtable Theme

Companies spend millions of dollars implementing project, program and portfolio management practices and systems. However, these systems often result in significantly more overhead and cost than planned and don’t deliver the anticipated business results. The business blames IT. IT blames the business and both often blame the tools and vendors. Where are the disconnects?

Flawed assumptions:
PPM tools will fix a broken process – Broken processes means a broken deployment
An executive-focused deployment will provide value and informed decision making – If the people on the floor aren’t using the tool to actually manage time and work, then the data is inherently flawed
Executives want to be able to see every little detail of a project – Executives want a 30,000 foot view and a platform to help establish trust. The average time for a CxO to make a go/no-go project decision is less than 2 minutes. (Gartner) Most of these decisions are based on the level of trust placed in the person requesting the project and not any objective metrics.
A tool will force conformity and good business practices – If based on a flawed process, or if insufficient training/value is communicated, it simply teaches people to find ways to work around the tool. Also provides the illusion of control since people learn how to “game the system”
PPM tools replace PMs – PPM tools increase the need for disciplined PMs with an understanding of the tools and business implications of the collected data. Increased visibility translates to increased need for business and financial skills in the PMs.
Project, Program and Portfolio management are part of a single career path – Project Management is an operational/People management discipline. Program management is a tactical/organizational management discipline and Portfolio Management is a strategic/financial/political discipline. There’s overlap, but it’s not an evolutionary ladder.  Forcing PMs into Portfolio Management roles is a recipe for disaster. Some will go willingly and successfully, but most will be getting set up for failure.
Executive sponsorship is essential – Many groups have been very successful in managing their own portfolio without direct executive sponsorship. Apocryphal evidence that bottom-up approaches may actually be more successful. (Less overall cultural impact?)

Things to do to be successful:
Essential that any tools are designed to meet the needs of the people doing the work.
-Collaborative project management and task/time tracking that EVERYBODY uses
-Make it easy for the project team to track their work and see how it fits into the “big picture”
-Managed and maintained document repositories
-“One view of the truth” – Big mistake to track the same data in different places
-Kill attachments. Force people to link to live documents

Train everybody. Repeat
-Create a training and information program to continually refresh knowledge of the system and to make sure that everyone understands how the tools are to be used and why. Informed decisions about the processes can’t be made without understanding how the data will be used.

PPM is doomed to failure if there aren’t mature processes in place BEFORE the tool is selected/deployed. Fix the processes and get buy-in from all levels before even thinking about a tool.

Implement “Just enough process”. Large cumbersome roadmaps, methodologies and inflexible frameworks provide little or no value to the people doing the work. Implement checklists and conditional frameworks (eg: If less than $100K, manage with a spreadsheet and checklist. If >$1M, full EVM with a predefined project model).

One large services company has extremely mature processes all based around Excel spreadsheets and Sharepoint. They’re managing a multi-billion dollar portfolio successfully and just starting to look at formal PPM tools. Evidence that the processes are more important than the tools. Good processes make up for bad tools, but the reverse is not true.

Don’t use the tool to promote consolidating into “Mega Projects”. Failure rates increase as project size and complexity are compounded. Segment projects into small (less than 3 months) components with quick measurable gains and manage each as “mini projects” with touchpoints.

Convert IT from a “technology value” mentality to a “business value” mentality. Portfolio management doesn’t work as long as that disconnect in viewpoints exists.
-“Business Value” doesn’t mean “Reduced Costs”. It usually means improved agility and an ability to respond to changing business needs. Cost is secondary to value.
-“Managed and Secure” doesn’t mean “Restrictive and policed”. Reasonable control of the environment and ensuring that we meet legal and regulatory obligations. Sometimes  it’s cheaper to pay a fine than it is to build an infrastructure to avoid it.
-IT needs to be an enabler with a “can do” attitude instead of an inhibitor locking down the environment and imposing controls that provide no business value.

Tool needs to be used in real-time
-Tool failed when used primarily as an annual planning tool. Successful when the process supported a real-time planning and approval process. Projects are entered as they’re envisioned and they dynamically develop through proposal, approval and scheduling. Annual planning is just an exercise in reconciling the budget needs for the next year rather than a mad scramble to create and justify the entire portfolio.

PPM Successes and high ROI
Engage the customer
-Don’t allow the customer to throw projects over the wall. Any PPM tools or processes need to fully engage the customer. If the customer disengages, there needs to be a mechanism to stop the project or at least throw up a red flag. PPM tools can help.

Be religious about requirements
-Set gates and project “drop dead” points for requirements. If the project is broken up into small enough phases or chunks, IT can stay agile while still saying “That will have to be shelved until the next phase”. The tool can lock down requirements, code and test cases.

Strict Change Management
-When a requirement changes, it needs to be documented and the PMO needs to have the authority to force a review of the schedule, budget and resources. Reports can be generated to show where requirements have changed and when the reviews didn’t occur.

Resource management and planning
-Mapping out projects as they become visible (rather than as approved) has allowed the organization to plan career development, develop staffing plans and to develop long-term communications strategies for any organizational changes. Resources feel more engaged as they’re trained for upcoming trends and projects instead of hiring external consultants at the last minute.

Align resources
-Skills inventories and the ability to see when resources are scheduled to become available allows easier scheduling and prioritizing of projects. Only works if the PPM system is real-time and the data is actually accurate.

Prune dead projects
-PMs know when projects are doomed, but are often forced to continue anyways. The tool provides visibility and forces stakeholders to be more objective.  Quarterly review and pruning of project occurs to make way for new projects and changing business needs.

Biggest single issue
Organization Change.  This is compounded if the organization isn’t prepared for the structure and visibility that PPM requires. Develop Processes first, then information sharing/visibility, then a tool. Get over the organizational issues and challenges before even considering a tool.

What’s the best way to powerfully engage attendees during a leadership seminar?

Hi. I used to teach leadership & psychology at West Point…and have been asked to teach/present a leadership seminar. The workshop on leadership (areas of focus in include physical/emotional rituals, behaviors that derail leaders, human performance engineering & a leadership vision for themselves & their organization). This content meets the needs of the client who’s paying for my work…so the issue of WHAT to pitch is set.

My question is this: what techniques or approaches have you seen (or used) that get the attendees’ attention, reactions and engagement?

For example, am thinking about starting with (1) having several people talk about their current role/responsibilities and (2) then suggesting that “what skills abilities got them HERE may not take them to the next level in their career. Later, will walk them through designing/writing their own vision statement.

Many thanks! Jack

Jack Cage

President, Cage Talent

One recommendation that I would make to anyone that leads these types of sessions would be to pick up a copy of “Aha! 10 Ways to Free Your Creative Spirit and Find Your Great Ideas” by Jordan Ayan. About 10 years ago, I had the pleasure of being in a workshop that he was brought in to moderate and it made me think about meetings and training in a completely different way. Even for something as simple as a project planning meeting or something as complex as corporate strategy development, the ideas and techniques for brainstorming and engagement still apply.

On a more immediate note, here are a few tricks that I use (some are pretty basic, but worth repeating):

1. Start the meeting on-time.
This sounds like a trivial item. But being late for a meeting is a subconcious statement that says “My time is more important than yours”. By starting on time, you’re immediately setting that stage for playing by the rules. I have a little trick to keep the upper hand and still allow for people playing this game. I put an agenda up on the projector that shows “Meeting room seating & setup – 10:00am, Meeting Start – 10:05”. Beleive it or not, it actually throws people to find out that they’re on-time. If someone is still actually late, make a point of dragging them in, getting the introduction and opening feedback, etc. DON’T let them sneak in to the meeting and skulk in the shadows.

2. Lay out the groundrules up-front.
-In the meeting everyone is equal. No levels or reporting structure
-Respect all opinions
-Agree to disagree. Make your point and move on
-Personality clashes and history need to get left at the door. All discussions need to be in the context of moving forward and not getting mired in history.

3. Have another person with you moderating or presenting. As a solo speaker, you may miss things going on in the room and the two of you can keep each other on track. Also, the occassional switching back and forth between speakers will often be enough to refocus your attendees (“Did the topic change? Are they asking a question?”)

4. At the beginning of the session, ask for introductions, but also ask what each person expects to get out of the meeting. Having a second person taking notes during this exercise is incredibly valuable. If you notice someone fading, try to tie a point back to what the individual said. eg: “And in this next slide we can see how we might address Jack’s goals of engaging his staff…” Nothing snaps a person back more than hearing their own name and having the room temporarily focus on them. Followup and ask if they see the connection or can think of ways to apply what has been said.

5. Don’t just ask for volunteers, get into the habit of polling around the entire room for feedback on key points. Start early to avoid embarassing anyone. Later on, find opportunities to poll the room whenever attention starts to waver.

6. Reward and encourage questions. A lot of people like to ask questions as a way to demonstrate their own insight and intelligence or, in some cases, to try to trip up the speaker. Try and use questions as an opportunity to get feedback from your attendees rather than as a platform for lecturing. eg: “How many other people have this issue? Can anyone offer suggestions on the best way to address this? Has anyone been successful in working through this issue? How?”. Once you have the feedback, you can add your own spin and answers. Use a lot of positive feedback like “That’s a great question.”, “I like that answer”, “I haven’t heard that approach before, That’s a really innovative solution”

7. Find opportunities to break the room up into small groups for problem solving, list building, etc. Mix up the groups throughout the day.

8. Force the group to have lunch together. Again, this sounds like a trivial thing, but you’ll get an additional level of comfort and openness that comes out of casual lunch time interaction.

John Benfield also suggests this expert on this topic:

• Jordan Ayan

In our federated model, we have almost no “hard” way (financially or in terms of people’s annual goals, etc.) of incenting people to participate and/or cooperate with new PMO governance, standards or processes. What tactics and/or techniques have you used to generate change and cooperations with the PMO?

Question from the Gartner Symposium Forums

Bear with me, this is a bit of a round-about answer.

In the most successful implementation that I was part of, we came at it a bit backwards from the “normal” way of doing things. Our PMO was viewed as a hindrance and as unnecessary administrative overhead. Part of that was because of ridiculous requirements like managing all projects (regardless of size or type) using EVM, preparing huge complex financial models for tiny operational initiatives, religious adherence to gate processes for projects that spanned only a few weeks or a handful of resources, etc.

My team originally came in to help the Applications team move to CMM level 2 and 3. However, shortly after starting the initiative, we realized that we were going to have to take a more holistic approach. We pulled together the PMO, Service Delivery, Finance and Quality teams and started to look at where the overlaps were and how we could combine CoBIT, SOX, ITIL, CMM and ISO initiatives. We didn’t take them over or try to replace them. We just worked with them to understand where we could tie them together with what we were doing.

We started by getting out into the field and explaining to the line workers why we needed to have processes, controls and measurements and how they would benefit them personally. At the same time, we found out where the problems were and why people resisted the PMO (and other initiatives). Since the PMO was a common element to all of the work that was being done, we ended up aligning most closely with them (and ultimately becoming part of the PMO).

We continued down the CMM path and trained analysts in process engineering and documentation (using UML) as part of our Requirements and Change Management KPAs. This eventually lined up with CoBIT and the same people that were building process docs for new IT projects ended up working with the business to document their processes. A lot of technical and business analysts ended up hopping the fence between the two disciplines.

We dismantled the existing “culture of punishment” and shifted to an advocacy culture where the PMO became a mediator to make sure that the business and IT both had a voice. We clearly delineated requirements into Business, Functional and Technical and made sure that ownership was clearly enforced (this also led to a level of requirements traceability that had been lacking. It also GREATLY helped with scope creep since the Business couldn’t change functionality without a business reason and IT couldn’t add or change features that weren’t supported by the functional requirements)

With the empowerment that came with this delineation, both the Business and IT started to view the PMO as being “their” ally against the “other side”. All of the processes and artifacts were presented in a way that demonstrated their value (the WIIFM perspective) and a lot of the “crap” got thrown away. The executives fought a little bit when we did away with a lot of the EVM reporting. But they were really just trying to make sure that the projects were under control. Once we explained the simplified mechanisms and increased visibility, communication and resolution of issues (rather than numbers that were being manipulated by the PMs anyways) the comfort level increased and people focused on getting the work done rather than generating status reports. PMs were positioned as taking the administrative burden off of the engineers, developers and analysts rather than as the “Khan of the Project”. Again, the explicit shifting of control and responsibility made for a better working relationship. PMs became mediators rather than enforcers and provided the people doing the work with a way to be heard.

I apologize if this is a bit disjointed, but it was an evolution that occurred over a 2+ year period and it’s difficult to encapsulate all of the cultural and behavioral changes that occurred. The CMM team and PMO were in a continual state of flux as we incorporated each new piece of feedback into subsequent training sessions and process definition. It really generated a domino effect when a team empowered by the CIO started listening to every level of worker and negotiating “just enough process” to meet everyone’s needs. Before that, it was executive edicts that were often poorly communicated, difficult to execute and that added value to only a very small audience. Once the real dialog began, the PMO became a true agent of transformation.

Don’t get me wrong, we still tracked schedules and costs directly from the Project artifacts. But the focus was on “why” targets were in jeopardy and how to get back on track rather than focusing on whose fault it was or how it could be covered up. If a project went red, the PMO response was “What can we do to help?” not “Whose fault was it?”. We still had the underlying PMBOK type of activities and processes, they were just set in a context of practical communication and mediation instead of adherence to theory, policing and punishment.

It wasn’t perfect, but it was remarkably successful.

Six Sigma, Lean, Rupp, Scrum, SDLC and more… how do you pick the right methodology for your organization?

Question from the Gartner Symposium Forums

In my experience, there is no “one true and only” methodology, model or framework. Of course, the problem then becomes that people become religious zealots rallying around “their” methodology. What’s really needed is a group that gathers the information, facilitates the sharing of best practices (regardless of the methodology) and helps the groups to realize how the methodologies and models can complement one another. Also, this can help to understand and where each methodology is most appropriate and effective. A similar discussion regularly comes up around ITIL, ISO 9K, CMM, CoBIT, TQM, etc.

Picture the Monday morning meeting that you have to attend after coming back from Symposium. It’s you and your CIO and SVPs. The Topic: What is one innovative/mind blowing idea should we (WE MUST!) start doing/implementing now.

For years we’ve heard about such topics as Real-Time Infrastructure, Server Virtualization, VOIP, Service-Oriented IT, ITIL and others.

I would submit that these topics are NOT innovative. To borrow a term, these topics are “birthright services” for I&O.

For some companies there are significant benefits to be gained by improving their implementation of some of these topics but you are not success in today’s game if you’re not doing this stuff! Every CIO has heard (heard the words but maybe not gotten the message) about these topics. Rehashing these same themes is not going to make an impact.

What’s innovative these days?

(Question from “capstick” on the Gartner Symposium Forums)

Honestly, I don’t believe that there’s anything really new. But there are a lot of “old” opportunities that a lot of IT groups aren’t exploiting.

The biggest one that I can think of is true collaboration with the business and a sense of partnership at all levels of the business and IT. At the top, that includes making sure that IT has a seat at the table. There needs to be a continuous dialog concerning what opportunities the business has and how IT can help to exploit them. Tools that provide the visibility (both ways) and facilitates that communication are part of that. But the behavior is the most important thing. Everything else is just an optimization exercise to squeeze out more work at less cost.

There are a few “game changing” technologies, but the real Innovation comes from process and culture changes, not from the tools themselves. IT should be a facilitator of Innovation and should be engaging the business to find the application and business value in the tools. To do that, we need to get out of the commoditization mindset and back into one of business partnership.

In rank order, what are the criteria you use to drive prioritization of the various projects and programs in your portfolio?

Question received via Gartner Symposium Forums

1. Discretionary vs Non-Discretionary

This requires the discipline to accurately categorize your projects. “Non-Discretionary” simply means that if you don’t act, something in the organization will break. Whether it’s a process, tool, or technology, there is a better than even chance that a failure to approve the project will result in damage to your business. This doesn’t mean that you miss an opportunity or you fail to make a sale. It means that you will suffer some sort of loss or degradation of your operation. A technology refresh is discretionary unless something is very likely to fail or put you into a position where you will be harmed by not upgrading.

Most organizations don’t have the stomach to draw the line that distinctly. “Non-discretionary” becomes “politically prudent” and “Discretionary” becomes “good to do, but nobody is really pushing for it”. The problem is that if you follow that model, you’re very likely to start cutting into Non-discretionary projects when money gets tight and there’s no way of knowing what was *really* critical to your survival. By definition, a non-discretionary project is something that has to be done or some other risk mitigation takes place. It can’t simply be rejected.

2. Required timeframe (is there a critical window of opportunity or risk?)

This applies to all projects. Again, many organizations put arbitrary schedules and timelines in place which undermines the ability of the portfolio manager to understand what the “real” time constraints are. When you establish your portfolio, there needs to be a clear distinction between a “requested date” and any actual time constraints on the project. Unfortunately, most tools that I’ve worked with don’t make that distinction.

3. Benefit (or risk avoidance)

Once you’ve determined the criticality and hard time constraints, then you can start looking at benefit realization or risk avoidance. Most organizations start here by prioritizing strictly based on ROI. However, the PMO and the project teams have to address the critical time-constrained projects in the margins to keep the company running. If your house is on fire, you need to deal with that first and not worry about selecting new carpets.

4. Cost/Cash flows

This and the next category are what’s going to control the actual flow and scheduling of your projects. Once you have your prioritization sequence in place, you can start allocating your cash flows for the next month, quarter or whatever planning calendar you work with. This allocation will end up being iterative with the next category. However, it’s important to recognize that resource constraints can often be addressed with external consultants or some other form of outsourcing. Budgetary constraints tend to be firm.

5. Resources

Once you know what you have to do, the windows for doing it and what money is available to do it, resources are the final gate. If you don’t have resources in-house, consider planning for the development of new resources in-house (time permitting), acquiring staff or outsourcing as appropriate. While this is the biggest practical limitation on executing your project, it’s also the one where you have the most flexibility.

Other factors such as strategic fit, synergies between projects/programs, missed opportunity costs, balancing the availability of critical resources, etc. all come into play as the portfolio is optimized. In addition, this is a recursive process. So sunk costs, project performance-to-date, and other metrics are also included in subsequent review, but may not be part of the official “checklist”. Instead, they become factored into the other elements like the anticipated benefits, risks and risk avoidance.

What’s more important in business process improvement initiatives – spending money on the technologies that enable them, or spending time changing the behavior of those involved in the process? And what are some best practices for doing the latter?

– Question from Gartner Symposium

Good tools just allow bad processes to fail faster and more efficiently. I’ve been part of a number of BPI/BPM initiatives and those that have tried to drive a process with the tool have ultimately failed (usually blaming their failure on the tool) while those that have built the processes and behaviors independently have been successful. In addition, tools come and go. Once the tool is gone or changed, the organization will backslide if they don’t understand and embrace the underlying processes and behaviors. Just ask any CMM, CoBIT or ITIL consultant.

The most pleasureable and smooth projects that I’ve worked on have been “bottom up”, allowing the people that do the work to be part of the process definition, analysis of the pain points and ultimately driving to a consistent set of processes that they feel pride and ownership in. Then the tool becomes just that; a tool to implement “their” process. We broke this down into a 6 step process:

-Develop Awareness – Explain why BPI and what’s in it for them. VERY IMPORTANT to be honest and direct as to why you want to do this. A lot of people assume that it’s a precursor to outsourcing/offshoring.

-Understand – Identify how they do things today and what their “pain points” are. Document the processes as they are and any issues. Don’t solve the problems. Just listen and document.

-Envision – What would make things better? In a perfect world, what would be changed? Define the ideal processes, procedures and workflows. Focus on what they can change and don’t let the group descend into complaining about things that they *can’t* change.

-Focus – Stress the goals of the overall BPI initiative and work with the workers to prioritize the proposed process changes.

-Implement – Implement, measure KPIs and publicize the successes. Address issues as things to be resolved, not as failures. Make sure that the team continues to be recognized for their improvements.

-Automate – Bring the process into a tool. While it’s generally easier to drop in a tool and use it to drive process, there is a bad habit of making the process fit the tool rather than the other way around.