Top 10 Skills in Demand in 2010 (PM is #1)

I recently read the Global Knowledge/TechRepublic 2010 Salary Survey results, where they asked:

“What skill set will your company be looking to add in 2010?”

And although there were many technical skills listed as are normally expected – the #1 was Project Management with Business Analysis making a come back in the top 5.  The reason they said was the need for organizations to acheive ROI via professional project planning and implementation.

I have even found that my clients are even doing ROI analysis – by doing “prove it to me” work after the project has completed to see if the project really delivered on what was outlined in the business plan that justified the work in the first place.

PMs still need to advance their status in Organizations:

According to an article on the Project Management Institute Web site, project managers still have to develop their

  • people skills,
  • organizational leadership, and
  • individual professionalism.

It isn’t enough to pass the PMP exam.   Team building, relationship building, team leadership -v- management and more are the skills organizations need us PMs to provide them.  And the broader lifecycle experience you can offer, the more valuable and in-demand you are to them.

BA’s need “faster pace” skills:

This economy has made companies think through their business problems and solutions.   Where the BA is playing the role of “liason among stakeholders” to gather requirements.    And IIBA says there are 3 types of BAs:

  1. Enterprise BAs – who identify opportunities for business change & define the work to be done
  2. Transition BAs – who fine-tunes the plans
  3. Project BAs – who work on project teams that implement the changes

People are more than titles – our skills define us…

Due to the faster pace times that started in the 90’s – starting the need for Agile-Lean approaches to be used — I have found that many of my fellow “seasoned PMs” have all these skills and are playing one or more of these roles to help bring focus and value to the customer and business.  Especially technical PM’s who have a business side to them – they not only can gather the requirements effectively, they also see the bigger picture of implementation.   Hence they are helping bridge the customer needs for the implementation team…so Agile-Lean methods can be used to produce value to customers faster.

** To read the entire survey by Global Knowledge/TechRepublic, go here



WEBINAR – Tools for Distributed Agile Meetings (2 Part Series)

Communication breakdown between remote locations will wreak havoc on a project. As team members struggle to effectively communicate, dysfunctional attitudes and inefficient practices endanger the team’s ability to deliver. Communication over multiple time zones, thousands of miles, and different cultures is not easy. As a result, d elivery risks on distributed projects will always increase.

“Can you hear me now?  Good . . .” is a two-part webinar series put on by ThoughtWorks designed to address those concerns and risks. The goal of this series is to provide immediate support and detailed suggestions to project teams struggling to work in this distributed environment.

Part 1: Tools for Distributed Agile Meetings

In Part 1 of this series will review and rate the best of breed tools that are available in the market to address the key communication challenges faced with distributed development. We will evaluate a variety of tools and what they do for your project, including: Instant Messenger/Chat Tools, Desktop Sharing, VOIP, Web Conferencing, Wiki/Collaboration Tools, Issue/Task Tracking Tools, and Application Lifecycle Management.  View Webinar  here

Part 2: Facilitating Distributed Agile Meetings

Part 2 of builds on the tool recommendations from Part 1 to focus on process and innovations used by effective project teams to facilitate four typical Agile meetings between remote locations: Distributed Release Planning Sessions, Distributed Iteration Planning Meetings, Distributed Stand Ups, and Distributed Retrospectives.  View Webinar here

mark rickmeierMark Rickmeier has over 9 years’ experience in the IT industry. As a project manager for many years, Mark specialized in Agile transformation and project governance with a focus on metrics and measurement. He has extensive distributed development experience working with project teams in Australia, India, China, Canada, the UK, and the US. His industry background includes equipment leasing, retail, insurance, healthcare and retail banking. He is currently a Client Principal at ThoughtWorks.



CASE STUDY – PART 2 – Proven, Practical Tactics For Agile IT Release Management (DEFINITIONS AND TRIAGE)


This article is the second in a series of five which explain how an IT organization delivered a release management process that exceeded its management’s expectations and provided a foundation for continued success. The series includes:

1. How did we get here – THE CONTEXT
2. First solution steps – DEFINITIONS AND TRIAGE
3. Intake and Release Planning – THE CORE SOLUTION
4. Production Change Control – FINAL QUALITY CONTROL
5. Metrics and Insights – LESSONS LEARNED


Many Information Technology organizations flounder when they are tasked to understand, organize and implement numerous changes to the system and application software serving their clients and end customers over a period of several years. This second article focuses on the very first steps of the solution I developed for the Release Management consulting engagement. Please refer to the first Article – THE CONTEXT for a full discussion of the problem domain and organization.   What was the secret sauce that made Release Management a success? The answer begins with core problem analysis, proposed solutions and a triage effort.


The company and its IT department clearly wanted a solution implemented that avoided historical mistakes. As a retained consultant, I conducted a series of one-on-one interviews, examined remnants of Change Control documents from a predecessor, investigated commercial off-the-shelf packages for both processes and operational tracking, and discovered the following core problems.

  • Problem #1 – What Trees are in this Forest? A substantial source of confusion and discussion involved defining the scope of what things should be controlled under the umbrella of Release Management and Change Control. There were divergent opinions about whether to include/exclude major projects, infrastructure changes from operations, bug fixes, hardware changes, Customer service changes, emergency patches, etc. As with most debates within IT, the stakeholders frequently used similar terms to mean very different things. Very specific language needed to be written, socialized and implemented that reduced this ambiguity and confusion.
  • Problem #2 – Who is Responsible for What? Projects were very clearly controlled end-to-end by Project Managers, and at any given time the 4 PMs would have 2-5 projects underway. These generally covered scope for multiple applications and multiple person-months of programming effort. Beyond that good start, Client Change Requests, Bug Fixes, Operations infrastructure changes, Customer service changes (move/update/fix my workstation) and emergency patches had no one role identified for control, communications and accountability throughout their life span. The IT assembly line for such work was disjointed at best and lacked fundamental structure. The role of Release Manager itself was undefined, with various stakeholders holding unique viewpoints on the scope of the assignment.
  • Problem #3 – How To Introduce Order Upon Chaos? This was a very critical concern, as the inflow of new requests from the business could not be halted, due to political and practical matters. If the organization knew tactically where it stood on Monday for every item, by Wednesday the landscape had changed, and priorities for older work were being adjusted on-the-fly, either overtly or covertly by business leadership.
  • Problem #4 – How Frequently Should We Release Change Packages? A practical concern was whether IT should embark on weekly, biweekly, monthly, quarterly or other frequency of planned production software change. The frequency of change would end up driving the timing of the real-world series of gates and meetings necessary for control and adjustment.   The first solution proposal entailed purchasing a complete software application and documentation package from a market leader that promised to cover the full scope of their interests. The alternative proposal was founded upon a low level of automation, and a high degree of inter-personal collaboration to achieve similar ends.


The CIO, facing this situation, agreed to allow the Manager for Project Management and Analysis to contract for a resource to implement Release Management (Version 2).   The CIO believed that she could deliver better results to her constituency by implementing change in a series of well-understood application package upgrades at regular intervals. She also wanted to take back to her peers a plan that they could understand and use to directly influence the order of implementation for their changes. The Manager of PM retained me as the Release Manager with the mandate to institute the processes and controls needed, and engaging all IT staff and VPs in business departments as needed for success.    The rest, they say, is “agile” history. To learn what it really takes, our story continues next with DEFINITIONS AND TRIAGE.


I will remark on Definitions first, because the management team needed to ground itself and communicate in a consistent fashion about the key objects and controls with Release Management processes.

Problem #1 – What Trees are in this Forest? – SOLUTION:

We took the perspective that anything that is planned to change the configuration of the production computing environment within the controlled data center and network configurations was subject to Release Management processes. As a result, we included:

·        Application software changes requested by clients or from IT itself (re-factoring, etc)
·        Application software fixes that were “not immediately damaging” clients’ business
·        Each software change package from projects (projects typically had more than one release package over several months)
·        Network or server infrastructure upgrades (OS, DBMS, middleware, hardware, etc.)

We excluded from Release Management processes:

·        Customer Service requests (fix/move my workstation, office moves, etc)
·        Emergency production software application fixes (fix it now)

This last exclusion was troublesome, but necessary. We assigned total responsibility for managing the emergency fixes to the Software Development Manager, and set an overall target to keep these to fewer than 5% of the total changes made into production. (We tracked the numbers, but didn’t stand in the way).   The practical outcome of these agreements was that each individual thing included in Release Management was a Change Request, to be initiated with a simple form. Each would be assigned a unique Number (and key attributes) and controlled in immediate form by an Excel spreadsheet updated and distributed by the Release Manager.

Problem #2 – Who is Responsible for What? — SOLUTIONS:

  • Single Point of Contact (SPOC) The organization had a good model of behavior and accountability for projects, but there was disjointed accountability for all the other Change Request types. To solve this, we defined a role called the Single Point of Contact (SPOC). The role was accountable for conveying the requirements, correct status of IT progress, and sponsoring the Change Request for its ultimate release to production. The SPOC was individually accountable for telling our clients the timing and impact of the implementation of a change, so that our clients were adequately prepped for a release. The assignments to this role were expected to last for the duration of the Change Request, as opposed to the previous pattern of shifting responsibility. As a practical matter, the SPOC assignments for 75% of the Change Requests fell into the Project Manager/Business Analysis team.
  • Architecture Review Board (ARB) The IT organization had a defined group called the Architecture Review Board (ARB) which convened to assess the technical and organizational impact and risks of major changes to the environment. This group consisted of the 5 IT Managers, the Applications Architect and the Operations Architect, and occasionally the CIO. As part of our definitional work it was determined that this group would exercise an expanded role – to quickly and routinely review each incoming change request. The Release Manager was added to the Board. This board was the “neck of the funnel” for all new items and through discussion, they determined rough size, priority, and impacts. The ARB also made the specific assignment of a SPOC to each new Change Request. More on the role of the ARB is covered in Article Three- Intake and Release Planning.
  • Release Planning Group (RPG) The primary organizational element that needed to be set in place was a new group titled Release Planning. This team, facilitated by the Release Manager, met with great discipline and regularity to organize, re-organize, and commit to a comprehensive, concrete order of implementation for all Change Requests. While this sounds straightforward on paper, remember that the context for this role was to organize +/- 325 Change Requests into a series of planned releases – and do this repeatedly as new things got added each week. This was a puzzle with ever-moving parts. The Release Planning Group consisted of the 5 IT Managers and the Release Manager. The Release Manager published the current Release Schedule as an outcome of each of the group’s meetings.
  • Change Control Board (CCB) This group was chaired by the Configuration Management leader, and had the responsibility to review and approve or defer the completed Change Requests for implementation in production. The Operations Manager and QA Manager played strong roles within this forum. The SPOCs for each Change Request were questioned for preparedness items, including the advance notification of the client communities. The CCB made a consensus decision on each Change Request and the outcome of these decisions allowed the Configuration Management Team to prepare the scripts and code packages for production upgrades.

Problem #3 – How To Introduce Order Upon Chaos?-SOLUTION

This fundamental problem afflicts all business organizations. Customer requirements constantly change in nature, new ones are added, and old ones wither yet refuse to die. Progress on the production line in IT is swift, stuttering, under-resourced, or overwhelmed. Managers independently made decisions from their own perspective of the best interests of the company. Frequency of change was sporadic.   To introduce order, the Release Manager defined a disciplined business cycle for Release Management Processes. The business cycle was a repetitive set of scheduled meetings of the Architectural Review Board, Release Planning Group, and Change Control Board that would be executed with defined agendas and deliverables, without failure, and with full participation of the people in their assigned roles. This business cycle would commence as soon as a triage of the Change Request queue of work could be completed. Customer feedback loops were defined for each stage of the process. Triage was a critical first step and is discussed further in this article.   The plan for this business cycle was presented to the CIO. She approved the plan for this business cycle, committed her management team to its principles, and successfully sold the plan to her peers in the company.

Problem #4 – How Frequently Should We Release Change Packages?- SOLUTION

The debate on this was not difficult – once we had made the earlier decisions to include operations change requests and exclude the emergency software fixes. We settled on a 2-week release change cycle. Our internal customers were already seeing changes made (or attempted) weekly with mid-week exceptions and surprises, so this could have been viewed as a step back by IT. However, the IT managers saw many shortcomings with more rapid attempts at change and were far more confident that the company would be well-served on a 2-week cycle. Specifically, change requests would be bundled together into a Release Change Package for implementation on alternate Thursday evenings. Our fallback position, if the Release did not succeed on Thursday night, would be to switch to a Friday evening implementation.


At this stage, the CIO evaluated how quickly all this good foundation work could be put into operation. As Release Manager, I advocated for a process solution supported by an industrial-strength commercial application that could be leveraged toward portfolio management, with many people updating their component parts, and project-specific support and tracking. However, finding, funding, purchasing and implementing such a baseline tool would require an estimated 3-4 months under ideal conditions. The CIO opted to proceed with the alternative “low-tech” approach for her organization. The mandate was to “find a way” to implement the essential processes by using the lowest-budget approach.   The mandate was daunting. The prior “Change Coordinator” person had worked from a Change Control log in Excel that had fallen into disuse. The root causes for that condition appeared to be that the information could never be kept current, plus it only covered some of the Change Requests. No one had previously been assigned the responsibility to actual know and communicate the status of “small” change requests – of which there were several hundred. The log also attempted to store a lot of interim dates on small changes, and it duplicated interim dates that Project Managers maintained in MSProject on regular projects. The SPOC role had not been defined. As far as we could tell, 285 Change Requests were “open” – meaning submitted by clients and not yet completed. That number fluctuated each week as new ones got added and some got finished, but no one was certain of the status of each item.

It seems appropriate to define the term triage (courtesy of   -noun

  1. the process of sorting victims, as of a battle or disaster, to determine medical priority in order to increase the number of survivors.
  2. the determination of priorities for action in an emergency.

The IT managers knew we couldn’t cope much longer with incorrect information about all the victims (Change Requests) that were littering our battlefield. As Release Manager, I asked them to devote the resources necessary to obtain a current, accurate view of the following for each Change Request:

1. Change Request Number
2. Customer Name
3. Change Request Label (very short description)
4. First Requested Date
5. Status (Open, Completed, Being Worked, Cancelled, or Duplicate) (if completed, wanted a completion date)
6. Target Release Date (Not Available was OK)
7. SPOC Name

I was responsible for facilitating the triage process. This roughly consisted of some very long all-manager meetings, publishing many versions of a new Release/Change Request log in Excel, assigning segments of the list to the most knowledgeable workers for update, and numerous interventions. The sorting process consisted of IT managers agreeing on an initial High, Medium or Low priority for an “early” Release Target per Change Request. Customer VPs were also polled on their priority settings for Change Requests. The process was declared “finished” in 3 weeks. We achieved a stable state of Change Request information in the log and were ready to begin Release Management processes and the business cycle for control.   The saga of Agile IT Release Management continues with THE CORE SOLUTION.

(c) By David W. Larsen

Article Source


CASE STUDY – PART 1 – Proven, Practical Tactics For Agile IT Release Management (THE PROBLEM)


This article is the first in a series of five that will explain how an IT organization delivered a release management process that exceeded its management’s expectations and provided a foundation for continued success. The series includes:

1.  How did we get here – THE CONTEXT
2.  First solution steps – DEFINITIONS AND TRIAGE
3.  Intake and Release Planning – THE CORE SOLUTION
4.  Production Change Control – FINAL QUALITY CONTROL
5.  Metrics and Insights – LESSONS LEARNED


Many Information Technology organizations flounder when they are tasked to understand, organize and implement numerous changes to the system and application software serving their clients and end customers over a period of several years. This article explains at a high level the very practical and common sense framework and processes that successfully conquered the problem for one corporation and its IT team. How successful was this framework? Frankly, IT metrics is a dangerous and obscure element to discuss scientifically. But this organization accomplished the following:

  • In one year, it increased its client satisfaction ranking from 2.5 to 4.0 on a 5 point scale.
  • In one year, it delivered 85% more change requests and projects into production than in the prior 12 months.
  • The organization exceeded its own stretch targets for throughput and change request cycle time by 40%.
  • It accomplished these results with no headcount increases and no expenditures for IT “toolware”.
  • It did increase the IT expense budget by 3.2% to cover the cost of a single consultant to instantiate the framework and processes for agile release management.

What was the secret sauce to make these accomplishments possible? The answer requires that we carefully consider the context for this organization.


The company and its IT department can be characterized as follows:

– Industry – telecommunications – one segment of a very large Regional Bell Operating Company
– Primary Products – voicemail service and ancillary features
– Consumer base – 4 million consumer accounts with 25% growth forecast
– Total company headcount – about 500 people
– Primary operation – a 24X7 call center of 300+ people selling and servicing consumers on voicemail products and features
– Financial Results – High Line-of-Business Profit Margins within very large corporate structure
– Everyone worked in the same building

IT Organization
– IT staff – about 60 – most with 2-10 years of organizational history
– Functionally aligned into – Operations, Project Management and Analysis, System Development, QA and Help Desk, Configuration Management
– Applications – 7 major home-grown subsystems serving the company’s direct operations
– HR/Financial/Corporate functions were served by corporate parent and processes, with interfaces
– Technology – fairly current languages, operating systems and technical infrastructure (hardware, network, DBMS)
– Recently installed improvements:

– Software Configuration management tools, staff and processes
– Perceived primary problem – no effective control of changes submitted to production
– Everyone worked on the same floor

– Strong and growing revenues
– Company Management – generally very experienced in call center management and product improvement processes
– IT Management – 80% had 4+ years within this organization and very little churn, only 2 levels of IT management
– Mature and successful IT processes included:

– Project Management

– Quality Assurance Testing
– Several strong IT manager advocates for improved Release Management
– Co-location of IT and its direct clients – the managers of the business functions

– Company managers negotiated private deals to get their change requests and projects installed “earlier”
– No central clearinghouse for adjudicating departmental requests for IT changes
– No tracking system to account for all change requests and projects demanded and delivered
– About 325 requests/projects believed to be in play
– A haphazard intake and control/tracking process for “small” change requests
– Programmers could independently implement an application change to production
– No single point of contact/communications between the IT organization for each small change request
– Current status and target implementation date of any single change request difficult to obtain/pin down
– IT operations changes were totally independent of organizational change control and viewed as disruptive

– A new chance to consolidate and share information on everything on IT’s plate in a single place
– A chance to leverage the existing knowledge and maturity of the IT staff
– A chance to reduce the start/stop nature of IT work due to competing and vociferous input from company managers
– A chance to incorporate IT infrastructure changes from Operations in a planned manner

– Software developers desired new toolware – not more management processes
– Company business managers enjoyed calling the shots directly with programming resources
– Tension between IT managers on what were the best paths for organizational improvement
– IT had failed on its first attempt the prior year at Change Control and Release Management processes
– Consultants rarely added value


The CIO, facing this situation, agreed to allow the Manager for Project Management and Analysis to contract for a resource to implement Release Management (Version 2). The CIO believed that she could deliver better results to her constituency by implementing change in a series of well-understood application package upgrades at regular intervals. She also wanted to take back to her peers a plan that they could understand and use to directly influence the order of implementation for their changes. The Manager of PM retained me as the Release Manager with the mandate to institute the processes and controls needed, and engaging all IT staff and VPs in business departments as needed for success.

The rest, they say, is “agile” history. To learn what it really takes, our story continues next with DEFINITIONS AND TRIAGE.

(c) By David W. Larsen

Article Source


Agile IT – is it possible?

I love the Biggest Loser Reality Show.   They show people loosing lots of weight in about 2-3 months.  It shows their struggles, their successes, and how they did it.

In reality we know it took them 6+ months to loose the weight.   And not just that – they had to change their entire life style of eating habits and exercise, how they thought, how they planned out meals and going out to dinner somewhere…..and so much more.

–  Did they all lose weight?   Yes !

–  Did some loose weight faster than others?   You bet?

–  Did they have to keep working on it after the show? Absolutely !.

Becoming an Agile IT organization is very similar.  Everyone can do it.   It takes work.  It takes time.  And it takes commitment to the process of change to see great results.

….and best of all – every IT employee can help make the adoption of Agile happen.

A Free Webinar from Thoughtworks [click here] is an excellent way to see how to do this.   Training is great, but it takes more than a class to make an organization change.


Business and IT – 8 Things they Hate about Each Other

Business is from Mars — IT is from Venus !!!!

Don’t laugh – it is really true.

Having worked on both sides of the playground – I had to laugh when I watched this slideshow.    It also reminded me that we need to understand each other to work together better.    If only we were aware and understood what each other hated, we might play nicer.    Instead of working as a team, I see a lot of BUSINESS -v- IT and We -v- Them going on.   Each one digging their heals in to get their way as if someone wins by doing that.   Instead, no one wins.

So what’s the answer?

It’s in a book coming out in March by Susan Cramm’s that discusses how be must

Move Beyond the Frustrations to Form a New Partnership

CIO Insight posted a great slideshow about the 8 things that Business and IT hate about each other [click here].  Let me know if you laugh, cry, or want to pull out the oozie.

I only wish they included “What IT and Business LOVE about each other”…..but I’m afraid that list would be much shorter !!!!


2010 Trends in Project Management

2010 brings with it multiple trends for Project Management.   It is not surprising that many of these trends will help mature the world of project management as we know it today.  Just as businesses must be flexible with market conditions – Project Management professionals and organizations must also adapt accordingly.

In talking to industry leaders in Project Management – several trends stand out.

Economic conditions have changed – Companies are changing – and project managers must understand these changes to be the leaders needed in 2010.

Trend 1 – Enterprises continue to look for Efficiencies in Process & Technology

Read more


WEBINAR – Applying Lean Thinking to IT Projects


In today’s business climate, “more-for -less” is becoming very important.  Applying “Lean Thinking” promises to deliver business results by greatly increasing quality, throughput, and productivity for organizations.  An understanding of “lean concepts” can be used by Project Managers to improve process and enable IT organizations to more efficiently and effectively meet customer needs.  This webinar with Carson Holmes will discuss lean practices that Project Managers can begin applying to IT Projects right away.

Read more

Are there Silver Bullets to IT projects? (10/26)

4:00 – webinars45:30 pm Eastern Time

*** FREE: Webinars are accredited with PDU codes by the PMI.

What works in IT Project Management and what doesn’t? Are there really any silver bullets? A “Silver Bullet” is something that magically transforms the performance of IT projects. But do such things exist? This is the second detailed analysis that the ISBSG has performed to discover the impact that the use of Techniques and Tools have on the performance of an IT project.

Read more


73% of Companies Investigating Virtual Desktop Infrastructure

vdi1…and about 70% have launched VDI solutions to at least some of their user groups already. Gartner says the worldwide hosted virtual desktop (HVD) market will accelerate through 2013 to reach 49 million units, up from more than 500,000 units in 2009.  And that worldwide HVD revenue will grow from 1% to 40% of the worldwide professional PC market.

Consider the large numbers here.  WOW !  Cost cutting advantages and simplified/centralized management are driving them to do this investigation (see “Cost-Cutting Potential of VDI” at

At the same time there are some obsticles holding up the move to VDI which the desktop brings — that servers and storage did not — since there are many more moving parts to the desktop.

Top barriers to implementing VDI have included …

Read more