Articles tagged with: Project-Management
Career, Headline, Patterns, Project-Management »
Photo by Christian Revival Network
Here’s a brief set of success patterns for program managers and project managers that I’ve shared with a few colleagues. These are the patterns I see that make a difference in getting results.
10 Success Patterns
Rapport before influence
Character trumps emotion trumps logic
Match their style
Distinguish between responsibility and authority
Turn chickens into pigs
Adapt, adjust, or avoid situations
Know the system.
Analyze it over time.
Success Patterns ExplainedHere’s the essence of each:
Empathic listening. Listen until the other person “feels” they’ve been heard. Once they feel heard, they’re more …
Photo by woodleywonderworks
What does it take to be an effective Program Manager at Microsoft? I’m responding to some requests for my take on what it takes to be an effective PM. I figured I could use a familiar 7 habits approach to help frame out a start.
To pick a set of habits, I started with a set of reference examples. I used the most effective and ineffective PMs that I’ve seen over time. I considered their track record, their ability to influence, and their leadership skills. Most importantly …
Photo by Lilly
How do you visualize the goal? Whenever you work on a project, one of the most important things to know is how the world will be different when you’re done. This is where expectations are set and how people get excited about what they’ll work on. This is how you’ll keep yourself going day in and day out throughout the project. In How to Run Successful Projects III: The Silver Bullet (3rd Edition), Fergus O’Connell provides a visualization checklist to help you visualize the end in …
A Scenario and Feature Frame is a quick way to show your project’s incremental value and dependencies. It’s helpful for showing your management what you’ll deliver in terms of a baseline release. It’s helpful for you in terms of finding ways to reduce dependencies. If you have a bunch of scenarios that depend on certain features, then you don’t have cuttable scope. The key is to find ways to factor your scope into incremental value.
Scenario and Feature FrameA Scenario and Feature Frame is a powerful tool for analyzing …
Project-Management, Requirements »
Photo by Wonderlane
What’s a scenario? Not everybody uses the term “scenario” the same way. In the software industry, there’s three common usages of scenario:
The same as a use case.
A path through a use case.
An instance of a use case.
Usually, the most helpful one is “an instance of a use case.” Why? Because if a scenario is an instance of a use case, then it’s testable with concrete data.
Lessons Learned at Microsoft
At Microsoft, when there’s a customer challenge to solve, it’s common to ask “what’s the scenario?” This …
Book Nuggets, Project-Management »
How do you create an effective work breakdown structure? A Work breakdown structure (WBS) is a powerful tool for improving your project success. An effective work breakdown structure is an informed list of the jobs for your project. You can think of a work breakdown structure as a map of the jobs to be done to complete the project. You can use the map to guide yourself, guide your team, and guide your stake holders. You can use your work breakdown structure to help understand time and budget requirements. …
patterns & practices »
This is one of my favorite figures that shows how we do solution engineering in patterns & practices at Microsoft:
It all starts with a scenario. It has to be a meaningful problem. You can’t evaluate an architecture in a vacuum. In order for us to build useful baseline architectures, we need to pick the right scenarios that flex the right engineering decisions.
Patterns are simply problem and solution pairs. In our case, we tend to focus on application, architecture or solution level patterns.
Baseline architectures are skeletal applications. They’re just …
How do you cure optimitis? Optimitis is an unhealthy, overly optimistic, unrealistic agreement to solving a problem. It ignores the tradeoffs. In Secrets of Consulting: A Guide to Giving and Getting Advice Successfully, Gerald M. Weinberg writes about how to cure optimitis.
OptimitisOptimitis is an overly optimistic and unrealistic agreement. Weinberg writes:
Optimitis can be found in anyone who is asked to produce solutions to problems. It is an inflammation of the optimization nerve, that part of the nervous system which responds to such requests as
“Give us the minimum cost solution.”
Just how much can people factors influence your project cost and effort? 24.6 percent! In other words, the least experienced team (the bottom 15 percent) can require up to 24.6 times as much effort to complete a project as the most experienced team (top 10 percent.) In Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers, Steve McConnell writes about the Cocomo II model and how personnel factors influence project cost and effort.
The Cocomo II ModelHow much do personnel factors influence the project’s cost and effort …
The Microsoft Solutions Framework (MSF) provides people and process guidance—the proven practices of Microsoft—to help teams and organizations become more successful in delivering business-driven technology solutions to their customers. Note that this MSF is not the same as the MSF Agile process included in VSTS. I like to be able to scan process methodologies. To do so, I create a skeletal view of the activities, artifacts, … etc. Here’s my notes on the Microsoft Solution Framework circa 2005, which might be a bit dated, but provide a quick lens into …
Book Nuggets, Project-Management »
How can you leverage XP practices in a fixed-price contract? One approach is to fix the price and the schedule, but somewhat vary the scope. You reduce risk by fixing the cost and schedule. Flexing the scope means that you can respond to the customer’s changing needs as you deliver value. You can think of this as the customer subscribing to your development team’s service for a period of time. In Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series), Kent Beck writes about how to deal with fixed …
How do you gradually shift responsibility for a system to the customer? How do you reduce the risk of a customer inheriting a system they can’t sustain? Rather than outsourcing, you can consider “insourcing.” In Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series), Kent Beck writes that insourcing is where you gradually replace the members of the team with technical folks from the customer.
Gradually Replace Team Members with the Customer
The “big thump” delivery of outsourcing violates the incremental change principle. There is a slight twist on outsourcing …
How can you be prepared to go in whatever direction the business or the system demands? Do you need to prepare for every possibility? No. Instead, you give up explicit preparation for any change. In Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series), Ken Beck writes that if you expect nothing, you can no longer be surprised.
Now You Are Ready to Learn
Beck writes about a student learning to become a swordsman. The master strikes the student each time his attention slips. The student becomes paranoid about getting whacked …
Do you need to adopt all of the Extreme Programming (XP) practices to get results? Can you adopt the XP practices piecemeal? In Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series), Kent Beck writes that you can adopt XP practices piecemeal, but the more you adopt, the more synergy you get.
The Full Value of XP Comes When All the Practices are in Place
The full value of XP will not come until all the practices are in place. Many of the practices can be adopted piecemeal, but their …
How do you know which path to take? How do you find your glass ceilings? Unless you’ve been there and done that, you need to test your path to avoid significant do-overs. In Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series), Kent Beck writes about architectural exploration.
The programmers should also experiment with architectural ideas — how do you build a system for multiple levels of undo? Implement it three different ways for a day and see which one feels best. These little architectural explorations are most …
Adding people to late projects makes them later. This can be counter-intuitive. In Requirements-Led Project Management: Discovering David’s Slingshot, by Suzanne Robertson and James Robertson explain how adding people to late projects makes them later.
The Least Knowledgeable People Prevent the Most Knowledgeable People from WorkingAccording to Suzanne and James, adding people to a late project, makes the project later:
The problem of adding people means disrupting the rhythm that your existing team has established. It increases the number of communication paths. New people penalize the existing team. When new members arrive, …
How do you know when you’re signing up for Mission Impossible? If your project has a short time frame to design, build, and deliver, and there’s high risk around the requirements and technology, there’s a good chance your project scenario is Mission Impossible. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maiden write about Mission Impossible scenarios.
Alexander and Maiden show a table that summarizes the project situation:
Is there a business need to get the product to market in the shortest time possible?
How do you choose between an Evolutionary, Incremental, or High-Risk software process model? Evolutionary, Incremental, and High-Risk are software process models for systems engineering ‘in the large’. In the Evolutionary model, the complete cycle of activities is repeated for each version. In the Incremental model, increments are individually designed, tested, and delivered at successive points in time. In the High-Risk model, the ‘in the large’ sequence involves successive phases in which project risks (user need, requirements, technology and fitness for purpose) are reduced in a controlled, step-wise fashion. In Scenarios, …
Evolutionary, Incremental, and High-Risk are software process models for systems engineering ‘in the large’. In the Evolutionary model, the complete cycle of activities is repeated for each version. In the Incremental model, increments are individually designed, tested, and delivered at successive points in time. In the high-risk model, the project is divided into phases and each phase helps constrain risk. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maiden write about the Evolutionary, Incremental, and High-Risk software process models for systems engineering ‘in …