HBR on Lean, Agile and IT Process Improvement
| Just read a Harvard Business Review blog which advocates leveraging your IT department for overall business process improvement. The author, Brad Power, cites how financial giants Nationwide and ING were able to take practices such as Lean and Agile used in their IT process improvements, to achieve more effective and efficient delivery of IT value for their organizations, to deploying it throughout the rest of the organization:
Building on their team successes, they created an "Agility capture team" of senior IT leaders to address larger issues. They have weekly planning meetings and conference calls twice a week to work on internal customer service improvements. While the IT organization is driving this, more importantly they have roped in business unit and functional heads to surface their needs. As a result, process improvement activities have begun rippling out from the IT project team level to the core operations of the business...
Building a new mindset of making many smaller changes and learning from each one, instead of getting a detailed specification and delivering it, has been a concerted cultural transformation. This continuous improvement thinking is well known in manufacturing, but few do it well or consistently...
Improving the performance of the IT department is hard enough. But by adopting the techniques of process improvement leaders, Nationwide and ING are doing what's nearly impossible at most large organizations: forming cross-functional teams to quickly design and implement better ways of serving customers and improving enterprise performance.
While I agree in general with the author, some of the blog comments in my opinion hit it dead on about the general perception of IT within most organizations. Ironically, through innovation in the US is typically associated with high tech companies especially in an area like Silicon Valley where companies such as Google, Cisco, Facebook and other notables reside, when you look at the majority of IT departments that is tasked with managing high tech systems in the corporate world, they are typically seen as a "keep the lights on" type of department. An unavoidable cost center and expense.
With the world in a prolonged recession and IT departments dealing with slashed budgets and limited resources, it is often hard enough just to manage and maintain corporate legacy IT systems, let alone take part in and become a strategic business partner to streamline and improve overall business operations and management. But this where project management is vital, since all major initiatives to deploy new technologies and/or to enhance and optimize existing technologies are done through projects. Especially projects that will help a company to deploy a new system that will enable it to become a market leader or capture untapped marketshare will have lots of visibility throughout all upper management ranks. So utilizing sound project and deployment practices such as Lean and Agile to get such projects done effciently and effectively will allow an IT department to demonstrate their ability to help the whole organization to achieve overall business efficiencies and continuous improvements. Since technology is now so ubiquitous throughout every business function and process in practically all companies around the world, the time is now to start seizing these kinds of opportunities. |
Agile Certification Adoption Metrics
| I saw this graphic on the Critical Path blog about the most recent number of PMI-ACP (Agile Certified Practitioner) certifications to be awarded in the month of January 2012:
The PMP is still the king of the hill at 4047 new PMPs, but the 2nd place finish of the ACP certification is pretty surprising given how new this is. As the blog states, "PMI-ACP reached a number in one month that took the other certification a few years". This got me thinking of the overall adoption of Agile/Scrum certifications and how to graph its progression. Thankfully, Google has a tool called "Google Insights for Search" that graphically shows the number of searches on their site for key terms. Typing in "Scrum Master Certification" revealed the following growth since 2004:
Since 2006, it has been an explosive growth! Typing "PMP Certification" revealed this graph:
Which shows a consisteny, yet slighly downward trend. When you combine the two, you see a surprising divergence:
I wouldn't read these as an authoritative graphical representations of the correlation of adoption between the two certifications or growing popularity of Agile/Scrum over PMI/PMBOK/PMP or visa versa, but it is interesting nevertheless. If anyone out there knows of or has a more rigorous research comparison I'd like to know. In the meantime, try out and play with Google's search insight. |
Crowdsourcing, Social Media and Agility
| There has been a lot of hype recently about the effectiveness of crowdsourcing that runs parallel to the hype around social networking, which is no surprise since each feed each other. A crowdsourcing project typically gets launch through some kind of social media platform like Facebook or Twitter, and if its popular enough it can go “viral” (to use another hyped term). A great recent example of a crowdsourcing project was the infamous Doritos commercial that aired on the Super Bowl.
This contest allowed consumers to submit their own Doritos commercials that could then be voted upon by the general public to select five finalists in which monetary prizes are given out. Obviously this went viral and generated nearly a million social media comments.
But what if your a project manager tasked with managing a crowdsourcing project? How would you go about managing such a project, especially if you don’t have a brand like Doritos and their deep pockets of funding?
I think before you even consider crowdsourcing a project, you need to have some preliminary items to think through:
In this type of situation, you will have to do Agile and beyond. Your crowd will have to be self-organizing. There is no choice, since you are not picking the crowd but rather hoping you generate enough of a crowd to get the talent you need. This will be achieved by having a large enough crowd such that it will suffice to get the talent you need by sheer scale, dumb luck or a combination thereof.
I think you will get iterations, but they will not be the well defined Sprints we are accustomed to, but rather waves of self-correcting iterations provided by the crowd. And rather than remove impediments as a typical ScrumMaster would do, your job will be to provide the right kinds of inducements, rewards or hype to keep the crowd active and moving forward.
Rather than fall to a traditional communication plan or attempt daily stand up meetings, you will have to be a master social media communicator that knows how to nip bad PR in the bud before it goes viral and ensure your updates or status gets linked (“Liked”) and forwarded (“Retweeted”) through the social network.
I’ve seen discussions on the topic of whether social media can be effective in project management. I think when it is done as I have outlined above, is when it can be most effective.
This contest allowed consumers to submit their own Doritos commercials that could then be voted upon by the general public to select five finalists in which monetary prizes are given out. Obviously this went viral and generated nearly a million social media comments.There has been a lot of hype recently about the effectiveness of crowdsourcing that runs parallel to the hype around social networking, which is no surprise since each feed each other. A crowdsourcing project typically gets launch through some kind of social media platform like Facebook or Twitter, and if its popular enough it can go “viral” (to use another hyped term. A great recent example of a crowdsourcing project was the infamous Doritos commercial that aired on the Super Bowl.
This contest allowed consumers to submit their own Doritos commercials that could then be voted upon by the general public to select five finalists in which monetary prizes are given out. Obviously this went viral and generated nearly a million social media comments.
|
PMBOK v5 Draft - More Agile integration
| The PMBOK v5 Guide Exposure Draft was made available to the public on February 17, 2012 and is available for public review and comments/recommendations by PMI members. What this means is that you have an opportunity to provide your feedback on the draft before it goes to final publication.
Here are some of the major changes I’ve seen:
The interesting sections for me were the continued addition of Agile terms and practices. Take this section on the “Adaptive Life Cycles”, section 2.4.2.4:
Adaptive life cycles (also known as change-driven or agile methods) are intended to facilitate change and require a high degree of ongoing stakeholder involvement. Adaptive methods are also iterative and incremental, but differ in that iterations are very rapid (usually 2 to 4 weeks in length) and are fixed in time and resources. Adaptive projects generally perform all processes in each iteration, although early iterations may concentrate on planning activities.
Sound very Scrumish and from this we can see why stakeholder management was spawned off as a separate knowledge area that is included in all the process groups except closing since “to facilitate change and require a high degree of ongoing stakeholder involvement”. Much as is advocated in Agile/Scrum is the need for constant customer engagement and feedback and this is now reflected in the draft version of the 5th edition PMBOK.
Rolling Wave Planning is more aligned with Agile in section 6.2.2.2:
Rolling wave planning is an iterative planning technique in which the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a more general level. It is a form of progressive elaboration. Therefore, work can exist at various levels of detail depending on where it is in the project life cycle.
For example, agile project management, originating in software development, uses iterative planning as a progression of rolling wave planning. The agile project team utilizes CPM scheduling for each development cycle (iteration). Agile project management focuses on shorter development cycles and tangible results for each iteration; the focus is on creating value instead of completing activities.
And in Section 6.7 regarding Control Schedule:
If an agile approach is utilized, control schedule is concerned with:
Determining the current status of the project schedule by comparing the total amount of work delivered and accepted against predictions of work completed for the time elapsed,
Conducting retrospective reviews (scheduled lessons learned reviews) for correcting processes and improving, if required,
Reprioritizing the remaining work plan (backlog),
Determining the rate of delivery (velocity) and acceptance of work per iteration (agreed work cycle duration, typically two weeks or one month),
Determining that the project schedule has changed, and
Managing the actual changes as they occur.
Mike Griffiths of the PM blog “Leading Answers” who worked on the Agile sections of the PMBOK states it pretty well when he says “never have I worked so hard, to write so little, about agile”, since as can be seen from the sections above, the draft PMBOK is articulating Agile practices, but is trying very hard not to be perceived as advocating Agile as Agile is generally practiced and known.
In my view, I can actually understand this rationale. Though I have seen studies that indicate that the majority if project managers who are studying the PMBOK for the PMP are in the IT industry, there are still many who are not and as a body of knowledge for general project management best practices, they need to be as agnostic as possible.
In any event, for those interested and with current PMI membership status I recommend you check it out.
In any event, for those interested and with current PMI membership status I recommend you check it out.The PMBOK v5 Guide Exposure Draft was made available for review on February 17, 2012 and is available for public review and comments/recommendations by members. What this means is that you have an opportunity to provide your feedback on the draft before it goes to final publication.
Here are some of the major changes I’ve seen:
They took out Chapter 3 (The Standard for Project Management) and placed it in the appendix since it is now an ANSI standard
The communications content that used to be part of Chapter 11 is now a new Chapter 13 titled “Stakeholder Engagement” which adds a new, 10th knowledge area called “Project Stakeholder Management”
The word “Plan” has been added to the knowledge areas in the Planning Process Group for items such as Scope, Schedule, Cost, and Stakeholder management much like it was in previous editions
There are now 47 processes in the 5th edition PMBOK Guide exposure draft as well as 614 input, tools and techniques and outputs which is about 15-20% more than the previous edition
The interesting sections for me were the continued addition of Agile terms and practices. Take this section on the “Adaptive Life Cycles”, section 2.4.2.4:
Adaptive life cycles (also known as change-driven or agile methods) are intended to facilitate change and require a high degree of ongoing stakeholder involvement. Adaptive methods are also iterative and incremental, but differ in that iterations are very rapid (usually 2 to 4 weeks in length) and are fixed in time and resources. Adaptive projects generally perform all processes in each iteration, although early iterations may concentrate on planning activities.
Sound very Scrumish and from this we can see why stakeholder management was spawned off as a separate knowledge area that is included in all the process groups except closing since “to facilitate change and require a high degree of ongoing stakeholder involvement”. Much as is advocated in Agile/Scrum is the need for constant customer engagement and feedback and this is now reflected in the draft version of the 5th edition PMBOK.
Rolling Wave Planning is more aligned with Agile in section 6.2.2.2:
Rolling wave planning is an iterative planning technique in which the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a more general level. It is a form of progressive elaboration. Therefore, work can exist at various levels of detail depending on where it is in the project life cycle.
For example, agile project management, originating in software development, uses iterative planning as a progression of rolling wave planning. The agile project team utilizes CPM scheduling for each development cycle (iteration). Agile project management focuses on shorter development cycles and tangible results for each iteration; the focus is on creating value instead of completing activities.
And in Section 6.7 regarding Control Schedule:
If an agile approach is utilized, control schedule is concerned with:
Determining the current status of the project schedule by comparing the total amount of work delivered and accepted against predictions of work completed for the time elapsed,
Conducting retrospective reviews (scheduled lessons learned reviews) for correcting processes and improving, if required,
Reprioritizing the remaining work plan (backlog),
Determining the rate of delivery (velocity) and acceptance of work per iteration (agreed work cycle duration, typically two weeks or one month),
Determining that the project schedule has changed, and
Managing the actual changes as they occur.
Mike Griffiths of the PM blog “Leading Answers” who worked on the Agile sections of the PMBOK states is pretty well when he says “never have I worked so hard, to write so little, about agile”, since as can be seen from the sections above, the draft PMBOK is articulating Agile practices, but is trying very hard not to be perceived as advocating Agile as Agile is generally practiced and known.
In my view, I can actually understand this rationale. Though I have seen studies that indicate that the majority if project managers who are studying the PMBOK for the PMP are in the IT industry, there are still many who are not and as a body of knowledge for general project management best practices, they need to be as agnostic as possible.
In any event, for those interested and with current PMI membership status I recommend you check it out.
|
Being a Lean-er Startup
| Here'a a video by author Eric Ries on being a lean-er startup:
This movement seems to be catching on quite well, and interestingly, much like the early days of project management that was done informally and with very little structure that now has many methods and best practices associated with it, Mr. Ries is arguing that launching and managing a startup can be put on a more systematic and scientific basis with methods and best practices from Lean and other business processes. Of course as anyone who has been involved with managing projects or with startup business ventures would know, that it is much as art as it is science, but I do applaud his efforts to put setting up a startup which is typically associated with chaos on a more firmer foundation. It is very similar to an idea I have about reconciling the best PM practices with startup business ventures. You can buy the book on Amazon: |









