Archive for September, 2010
8 Golden Rules When Starting New Projects
By Petrus Keyter
Starting a new project can be a daunting task, especially when you are new to project management. Many project management methodologies concentrates very much on theory, without providing actual practical examples of how to implement the learnt methodology.
In order to ensure project success when starting a new [...]
Project managers must plan realistically, assessing the factors lying ahead that could threaten the project. Other factors at present are unknown and cannot be measured. Read about project management uncertainty vs risk here and learn how to approach each effectively. Project Management Risk Risk management activities seek to assess what factors an…
Il lavoro del Project Manager / Dirigente comporta l’uso non solo di molte energie fisiche, ma
I’ll be joining the Project Management Fundamentals 8 training in Cebu on October 11 – 15. I am exp
The CWG project management fiasco raised many questions. If there is any most difficult job in the w
The CWG project management fiasco raised many questions. If there is any most difficult job in the w
Alright! So I’ve gone through PMI’s PMBOK but never had the chance to take a PMI exam to become a PM
Project management is an important factor within certain businesses and companies and there are certainly many requests for people that have project management skills. But what is project management? Why is it important? And what do those people do? Project Management There are a lot people and roles that can be attributed to project ma…
Issue Tracking, the foundation of just about any project management. As a build engineer I am const
Part 0 of 7 Introduction
Part 1 of 7 Wrong Focus
Part 2 of 7 Developer Creativity
Part 3 of 7 Stakeout Stakeholders
Part 3 of 7: Stakeout Stakeholders or Stakeholders will stake you out.
Agile theory, teachings and practices mainly* focus on the users and sometimes the customer. They preach use-cases, user stories and the customer-in-the-next-room type techniques.
- *I’m sure someone can and will point to projects that takes a wider approach to Stakeholders. I applaud and support that. Please link to sensible information about capturing complete set of Stakeholders, especially those that target Stakeholders that are not customer and users. I’m in support, not against great Agile implementations. Yet 95% of what I see practiced, written, thought, and preached takes the limited approach to Stakeholders.
Any system being developed has multiple Stakeholders. Stakeholders being the people, groups and things (laws, other systems etc.) that have Requirements related to the system. Stakeholders have a ‘stake’ in the system. Critical Stakeholders can potentially determine success and failure of the system. Stakeholders require something from the system.
Illustration: Stakeholder Map by Suzanne Robertson & James Robertson
To have a fighting chance at understanding the Requirements of a system, identify all critical Stakeholders. Then identify, capture, communicate, develop, deliver and tune their requirements.
Typically one or a few people initially represents a Stakeholder group and their requirements. It is unlikely that the representatives can understand the diverse needs of their group, therefore I also recommend, where at all possible, to deliver value directly to the actual Stakeholders, get their feedback, then learn and change based on the feedback. Don’t stop at demonstrating working software, rather, early and frequently, deliver real value to real Stakeholders.
Yes, users and customers are critical Stakeholder groups. What I’m missing are the other 20 to 40 Stakeholder groups that all have Requirements for our systems, Stakeholders and Requirements that can and will determine the success or failure of the system being developed.
Illustration: Here is an example from multi discipline industrial designers and design managers of thinking about multiple Stakeholders and their needs. -Providing Design Strategy for Winning Products and Successful Enterprises
by Mordechai Rotenberg – http://m-rotenberg-design-management.com
Until the popular agile practices systematically incorporate the Requirements from a complete set of Stakeholders, they will remain unfit for any but the simplest of projects. Scaling agile without capturing the larger Stakeholder set and their Requirements might somewhat work when the scaling is in the direction of doing more volume of simple commodity work. Without capturing the larger Stakeholder set and their Requirements, I doubt agile will find much success in trying to Scale towards larger, complex, high quality or competitive products.
Stakeout the Stakeholders or the Stakeholders will stake you out.
To comment, you need to register (instant) and log in (top right).
Yours truly
Kai Gilb
Part 0 of 7 Introduction
Part 1 of 7 Wrong Focus
Part 2 of 7 Developer Creativity
Part 3 of 7 Stakeout Stakeholders
In the last blog post, Part 2 of 7 Developer Creativity, I posted this challenge,
I like to pass on a challenge one of my customers had. He was given a project from Microsoft, to implement a Microsoft built Customer Relationship Management (CRM) system at a telephone operator company. He was the Product Owner. He had about 6 months to roll out the system to all the employees there using CRM systems.
Your challenge: By using Scrum, XP or any other Agile framework or method, how would you write the product backlog items or the requirements? I understand if you think I have given you too little information, but give it a go anyway. Just give me some examples of how you would specify the Product Backlog Items in our Blog comment section, or at least think about it for yourself, later I will tell you what he actually did, and then you can compare.
The challenge got one response from one brave person, thanks ?
Well, what my customer (student), Jens Egil Evensen (jens.egil.evensen at logica dot com), actually did was.
1. Identify the critical Stakeholders.
- Number one was the CTO who was sold the system from Microsoft.
2. Talk to them, and find the value improvements they are hoping for.
- The CTO said (after no compromise questioning of, – why? – what do you want to archive?, where he initially was stuck on the idea of rolling out the CRM system) they where loosing €9.300.000.- per year in expiring contracts, and they did not know about them before after the contracts had expired and the customer was lost.
3. Identify solutions, 4. Divide them into value deliveries, 5. Develop (using Scrum) and
6. Deliver value early.
- After 14 days, he delivered a system (based on the MS CRM system) to the desk of the CTO, that hooked into the telephone operators customer contract system, flagged the outgoing contracts about 30 days before expiration, and sent a message to the appropriate people to take action.
From that day onwards, and to this date, the telephone operator was saving about €9.300.000.- every year.
The point being that if Jens had followed any kind of Requirement method as taught and practiced by the Agile community, based on functions, features, user stories and the like. He would have utterly failed. Jens would not have identified the Stakeholders, he would not have talked to the CTO, he would not have asked the right questions. What he would have done is rolled out a CRM system bit by bit?
Jens went on to roll out the CRM system going through the cycle 1 to 8 (7=Measure, 8=Learn). He was given all Resources (guess why!) and the CRM implementation has since won an award that MS is busy taking credit for ?
Have fun communicating with your Stakeholders.
