Mark’s new story for Information Management on project portfolio management best practices in an Agile organization has been published. You can read it here.
Use our blog tag cloud to uncover more info on TechProdo’s discussions, best practices, experiences and more. Here is a direct link to our blogs on Agile . I am still cleaning-up our Forums site after we got bombed from spammers … But I hope to have the Agile Product Manager Manifesto forum back up this weekend.
Thanks & enjoy!
Andrew Makar has a nice post up on Gantthead available here that mentions a key component of a PM’s toolbox should be a business process modeling tool. I couldn’t agree more but would take it one step further in saying that you can gain efficencies with higher-end BPM tools that use BPMN or BPEL so that engineers and developers can then take your high-level business model from that tool and transform it into classes & code for execution of your model. I have much more on this in our TechProdo forum on business process management here.
I was having a discussion with a program manager from another company last week about project management techniques and we started discussing what were some of the most difficult and complex projects that we’ve worked on in our careers. My career spans 16 years and I’ve been a PM on projects from large national system deployments to small development projects. I’ve seen waterfall projects, RUP, Agile and everywhere in between.
We both are big advocates of Agile in software development teams and are most definitely converts to the ideas of Agile from all aspects: product management, project management and development management.
But she challenged me with this: I said that the most challenging project that I ever worked on was a 2-year complex project for AT&T that deployed network operations systems across the entire United States, had hundreds of project participants, disconnected and non-collocated teams and no system in place to properly manage and collaborate on project initiatives. Her challenge question was, “Would Agile have worked in this scenario and would it have solved the problems of communication failures, project delays and overruns?”
I initially shouted out: “SURE!” Agile solves all ills … Then I thought to myself, “wait a second …” There would have been no way to coordinate Scrums, organize the teams in a way that they are not used to working, there were no Scrum masters, etc. That may be getting too stuck on the logistics and organizational structure at that time. Perhaps we could have stepped-back and implemented Scrum teams and worked through progressively elaborated lean scheduling.
To me, the bottom-line is this: Agile is proven in smaller teams on smaller-sized projects were not all of the requirements are known up-front, where lengthy analysis and documentation is not required at the outset. For projects that are contractually bound and have high risks of litigation and structured SLAs and SOWs at the outset, Agile may not fit.
What are your thoughts? Have you seen successful implementations of Agile self-forming, self-managing small teams cluster together on large complex projects that are not software development projects? Will this work?
InfoQ has a good recording of a session from the Agile 2009 Conference by Gerard Meszaros that details his experiences in planning and balancing JIT vs. deferred decision making. I am linking to it here and I recommend you take some time to listen to it if you are working in an environment as a PM in an Agile org.
What I wanted to also point out is my slight variation on his “Five Levels of Agile Planning”. Here are Gerard’s: Product vision, product roadmap, release plan, iteration plan, daily plan.
But in my experience, I don’t find daily stand-ups really to be a “plan”. That is much more JIT task-master work. From an Agile PM’s perspective, I would instead focus on these Five Areas of Planning: Portfolio Management, Product Roadmap, Product BRD, product backlog, release backlog. As a PM (program, project or product), your interaction at the release backlog may vary and may not be very deep. In fact, not all organizations following Agile methodologies use relase backlogs. More importantly, note that I included BRD in the list. I feel it is still important for someone in a “strategy” role, perhaps not a product owner, to own, document and detail product strategy in a BRD.
Lastly, I did want to mention that there is much more quality content in his session that you should check out and also that Gerard seems to slide between Scrum & XP throughout the talk.
I think we’d all agree that collaboration in these days of Web 2.0 and Enterprise 2.0 is important, requested by users and here to stay. But how much does that actually need to be embedded in common business functions such as project management, business process management, budgeting, planning, etc?
I ask, because I am researching several ERP-based projects and collaboration keeps surfacing as a high-priority requirement. But is it necessary to enable collaboration directly in business applications?
What are your thoughts?
I put my thoughts directly into this EBizQ thread here. In talking with customers and analysts, my thoughts are that the requirement is likely satisfied through collaborative platforms such as SharePoint, Notes, Google Wave or Beehive. This would put less of an emphasis on enabling real-time multi-user collaboration into budget plans, capital plans, project plans, BPMN models, etc. and rely more on collaboration capabilities of a tool that enables virtual meetings, idea sharing, Wikis, etc.
by Mark Kromer
I am starting a new series on risks & alternatives in all areas that I focus on for this blog: product, project & program management, within the context of software technology. In all of those areas the first thing to do is to perform exercises and common practices that lead to identification both of potential risks and then viable alternatives. Mitigation, plans and analysis will come later and I’ll touch on those in the next parts of the series.
In a project, a risk is an event that can negatively (or positively, according to PMI) effect the outcome of your project. In products, a risk is similar but is more of a business case item such as those that are captured through market research in a SWOT analysis or in a cost/benefit scenario. And program management would cover risks from a resource or investment perspective.
In all cases, identifying alternatives is key to mitigating risks and to identifying the risks associated with not just the current strategy, but alternative strategies as well so that your stakeholders and decision-makers are given the best tools, outlooks and data to make the right decision on project, products or programs.
For project managers, PMI recommends using an RBS or risk breakdown structure to list out risks for projects and they also list many different techniques for what is one of the most difficult exercises in risk identification, which is getting all of the risks from the stakeholders, project members, etc. The usual techniques are brainstorming, interviews and virtual meetings with or without anonymity. As a PM, it is your responsible to figure out which technique works bets for the product, project, program and audience.
For a couple of rules of thumb here is what I have found in practice:
No matter how you decide to approach this first initial step of risk identification, you must be certain that this is an on-going repeated process. You are not likely to identify all risks and alternatives up-front. And you are likely going to have to work hard to pry the information out of the teams. So research your topics for your product or project and make sure that the risk register, business case, or whatever format you use to track risks & alternatives is constantly updated and validated.
Written from a project manager’s perspective, this is a presentation by Lois Zells, author, lecturer, and business consultant, specializing in software engineering consulting, that I really enjoyed reading. I came across it from my membership in my local PMI chapter as a resource they made available after she spoke to the audience about what she has perceived as some of the pitfalls of Agile Scrum, XP and other iterative software engineering processes.
If you are invovled in the engineering side of the business and work with or as project management, you may find this a great read. I don’t agree with all of her points of the downside to iterative or Agile. Particularly, my main issue with her take is that it very much is in line with the classic PMP or PMI negative attitude toward the lack of process, change management and documentation from development teams that abide stringently by the Agile Manifesto.
But one of my favorite parts of her presentation, which I linked to above, I have pasted here below to call out in particular because I felt it was funny, spot-on and classic when implementing, developing or planning new technologies:
Lois Zells New Technology Project Lifecycle
If you are interested in learning more about portfolio management and project management, something that I practice and frequently speak about in terms of product management roles, I just entered a new posting on BEYE blogs discussing the purpose of decision trees as described by PMI in the PMBOK for decision trees in decision analysis: http://www.beyeblogs.com/bippm/.
by Mark Kromer
I stumbled across this story from SearchSoftwareQuality by Colleen Frye about aspects of the Project Management Book of Knowledge (PMBOK) from the Project Management Institute. It is a good read and references another very good article from Forrester called The PMBOK and Agile: Friends or Foes, which I also recommend, if you have access to that material on Forrester’s site.
Anyway, reading this has proded me to continue my series that I started after receiving my PMP certification credential this year. Here is the 1st part of the series … So let’s talk a little bit about other areas of the PMP that I feel bring value to you as a product manager and since I’ve reference the 2 stories above about Agile Product & Project Management specifically, let’s stay on topic and stick with agile for now.
Many people tell me they believe that PMBOK and agile in a software development context offer 2 completely different ways to attack problems of software engineering projects. True. But there are areas of value in learning and applying the PMP style of project management even if your entire team from product managers to project managers to business analysts to developers are knee-deep in agile, scrum, sprints, etc.
Check out the stories I reference above for other good examples. But here are mine:
1. Project initiation. PMBOK does an outstanding job of providing guidance in both projects and the PMI program certs as well, in regards of assessing needs, ROI, cost/benefit and a systematic way of addressing costs & benefits BEFORE engaging on a project. This is an area where I feel that the Agile Manifesto ideas of less documentation and conversation of negotiation should be avoided. You need to make solid long-term business decisions from a pragmatic strategic approach. Not a trial & error approach.
2.Project closure. I spent several months working on a new product project for Primavera Systems in 2008 and their large-project customers gave me wonderful insight into how powerful it can be accumulate, index, store and learn from project lessons and build a knowledge base. PMBOK provides good guidance on how to document and perform these steps. This is best accomplished by an PMP-style project manager and to release the agile developers from this requirement. Besides, they probably won’t want to do this anyway!
3. Continuous improvement. A big part of the PMP exam centered around steps & procedures to create an on-going feedback loop of lessons learned, quality measures and other areas where the macro business process of software engineering in your oranization can be improved. This is best performed by a PMP project manager as opposed to the heads-down agile development teams.
© 2010 Techprodo Blogspot · Proudly powered by WordPress & Green Park 2 by Cordobo.
Valid XHTML 1.0 Transitional | Valid CSS 3
