Friday, November 30. 2007
Joel Spolsky, a person frequently mentioned on this blog, has developed an intriguing product that is quite straigthforward, and long over due! Their product features Evidence Based Scheduling, which allows an automated estimation of ship dates, and the probability chart of a successful ship date is automatically deduced from past history.
This is going to be extremely powerful for Program Managers. See the link here:
http://www.joelonsoftware.com/items/2007/10/26.html
Friday, October 27. 2006
The following link contains some excellent presentation tips. Simple, easy reading, and recommended for anyone who ever has give presentations.
I especially like the idea of blank slides, "silence" within the song.
The article's purpose is to compare Bill Gate's and Steve Job's presentation styles measured against Zen philosophy, but it stands well upon it's own...
http://presentationzen.blogs.com/presentationzen/2005/11/the_zen_estheti.html
Tuesday, June 20. 2006
Have you ever met a manager that left you walking away with more uncertainty than you started out with? Or have you walked away clear and certain on your objectives and expectations, dove in headfirst, and proudly delivered your product only to be dismayed as you discover the deliverables were not in line with said expectations? Very often, they'll point to some bullet in some list they created from a conversation you had in which they did not understand a piece of information, leaving you with a defensive mode and trying to re-iterate your past communication, which seems to appear merely as a bad excuse.
As a good practical program manager, I often find myself disorganized as I take on bits and pieces of "disorganized stuff"... But that's the strength of a good program manager.
Take away those pieces that leave others confused and unclear, and take responsibility for them, so that they are free to get the real work done. Sure...your left with an ambigous mess of uncertainty and issues, but that's your job!
Thursday, March 23. 2006
As information flows, people become more comfortable. They understand their environment better. Even bad information with a confidence level can make a person feel more secure in their risk-reward ratio, and respond appropriately. Among those lines, there is a trend I've noticed.
When information flows freely and there is little change, people tend to gather in more diverse groups. People from very different backgrounds can feel comfortable sharing their perspectives. They fear not the judgment others may place on them by their enthusiasm or skepticism of unique ideas. People are more comfortable proposing challenging goals, and endeavor hard to exceed expectations, sometimes just to see if they can.
When information flows poorly, and there is much change, an opposite effect occurs. People tend to gather in more relational groups. It is such an effective metric that when I interview with companies, I look closely at whether those gathered together chatting in hallways are seemingly diverse or closely knit. Sometimes I'll see complete diversity, and it inspires a free thought atmosphere. Sometimes I'll see small groups of related people gathering, as though artificially grouped by a educational, political, or ethnic background.
At one company, upon joining, I was inspired and in awe of the immense diversity, and the ability for others to listen closely to the most foreign of ideas...and not only absorb those ideas, but relate them to others. After many re-orgs, new processes, and a lack of information flow, I was stunned only 8 months later to walk in one day and see Asians talking to Asians, Indians talking to Indians, Midwest Americans talking to Midwest Americans, and a untold few who silently never feared the unknown, walking around in isolation and confusion, intermixed with uncertainty, roaming among the hallways.
It's a very important metric that tells you the level of confidence people have. And confidence is the one criteria that makes people excel in a competitive world… Without confidence, people cluster among family looking for sure things and handouts. With confidence, people reach out to new communities to grow themselves and their reach.
Sunday, February 19. 2006
An innovationTools article talks about managing highly innovative projects and programs.
- Innovation projects tend to start with loosely defined, sometimes even ambiguous objectives that become clearer as the project proceeds. The processes used are more experimental and exploratory and seldom follow strict linear guidelines.
- Teams need to be more diverse and have a higher level of trust as they explore new territory where failure is a possibility.
- With failure as a built-in possibility, innovation teams are more actively involved with risk management and need to learn to fail fast and fail smart in order to move on to more attractive options.
- Also, innovation projects generally need to be sold to project sponsors and funding committees, a responsibility usually not required from normal project teams.
Saturday, February 11. 2006
Tuesday, February 7. 2006
Joel Spolsky has a new series of articles about great design.
On designing a trashcan:
Ok, light, heavy, big, and small. What else. It should be closed on the top, so rubbish doesn't fly away in the wind. It should be open on the top, so it's easy to throw things away.
I'm looking forward to reading the rest of it:
User Model vs. Program Model
Choices
Affordances and Metaphors
Broken Metaphors
Consistency and Hobgoblins
Modes
Put users in control
Design for Extremes
Users don't read
Users can't control the mouse
Users can't remember anything
Activity Based Design
Usability Testing
Relativity (UI Time Warps)
How Do It Know?
Tricks of the Trade
UIs that Kill
Beta Testing
The Onion in the Varnish
Information Design / Answering the Right Question
Shipping is a Feature
Great Design
Introduction to Black Magic of Great Design
Aesthetics
Emotional Design
Designing the Social Interface
Building Communities
Obsessive Attention to Detail
Taking Things Away
Playing with Fire (making things worse)
User happiness vs. user success
Sunday, January 22. 2006
Here are a few more interesting PM reads I've stumbled across...
What it's like to be a Program Manager at Microsoft... by By KC Lemson
PM's as therapists by Vernal
What does a Program Manager do? by Bill Can
Scott Berkun has several good articles, but here's a PMI presentation he gave in Seattle.
This is a repost to allow LiveDocumentRSS to register this post.
Program Management Cheat-sheet
By Edward Becker
- Clear Mission Statement/Objective(s)
- Clear Project Sponsor
- Clear Project Clients/Stakeholders
- Use Cases derived from Business needs
- Requirements derived from Use cases - Scoped to resources available - Scoped to immediate customer needs
- Assumptions
- Architecture is based on platform/system/business applications/visual interface support and interoperability requirements.
- High Level design is milestone-driven (not time-based or event based)
- Low level Design is milestone-driven (not time-based or event based)...Visual interfaces spec'd at this level
- Dependencies
- Task planning (event-based) (incorporates project processes (build/architecture/dev/test/ops - identify resources)
- Clear communication Plan (event* based)
- Task follow up (event* based) (measure of progress)
- Task follow up (time* based) (Schedule management)
- Feedback plan (event* based)
- Constraints
- Risk Plan
- Test Plan (measure!)
- Rollout plan
- Operational Plan
- End-of-life assessment frequency (exit/upgrade strategies)
- Post-Mortem
- Events can be time-based (day/week/etc), milestone-based (product-driven), event based (process driven -Milestones "are miniature objective/mission statements “
-A clear communication plan should imply additional informal relationship management strategy (luncheons, one-one's, after-hour events
-The Event-based task follow up gives you accurate measure of progress (based on reporting of events via feedback plan), whereas the new time time-based task follow up forces you to assess (via the perception of task owners adjusted with estimated vs. actual time) and manage the schedule.
-Company standards/templates are valuable for achieving clarity quickly, but don't be afraid to break those standards when they reduce clarity!
-All documentation resulting from steps above should be reviewed and subject to scrutiny by those impacted.
* LEAD: All planning and communication should consider:
- Self-awareness (recognize your personal aspirations/goals/morals/strengths/weaknesses/confidence)
- Self-Management (Identify and fulfill owned tasks)
- Social-Awareness (Perception is everything/recognize business goals)
- Relationship management (guide everyone in right direction with resonance, consider their self as well as their self-awareness.)
Consider: User Documenation/Education/Localization
Sunday, January 15. 2006
In a Conversation with Phil Smoot, product unit manager in Microsoft’s MSN division, Phil discusses large-scale megaservice Hotmail.
BF Here’s the ultimate open-ended question: If you were to talk to someone who was about to walk into a situation managing or operating and engineering a megaservice, or was thinking about creating such a service from scratch, what kind of advice would you give? What questions would you want this person to keep in mind?
PS I’d see if this person really wants to do it. Has he or she considered teaching? The best advice is just basically to keep everything as simple as possible—simple processes, simple SKUs, simple engineering. These systems get to be very big very fast. I don’t think there’s really any one particularly hard, gnarly problem, but when you add them all up, there are lots and lots of little problems. As long as you can keep each of those pieces simple, that seems to be the key. It’s more of a philosophy, I think, than anything else. (emphasis mine).
I can't imagine a technical program manager who won't benefit from reading the interview.
Chris Sells, a Program Manager in the Distributed Systems Group at Microsoft, has an excellent site on Program Management skills. Definitely a must-read.
I'm interested in comparing my PM cheat sheet to his skill number 4: Getting Things Done.
Sunday, January 1. 2006
Anyone unfamiliar to the role of a program manager is instantly confronted with this question, and it's no surprise they end up at Microsoft's excellent overview.
Many have worked with program manager's and are very familiar with the role, so you can skip ahead to the question "What does a program manager wear in Jan 2006?". For the uninitiated, however, the first question you may have is "Isn't that a project manager?"
The answer is no. It's horrible first question, and it makes for a boring first answer:
Throughout many companies, the number of which I don't know (Does anybody have statistics for industry-adoption of the technical program management role?), it's still very common to not have program managers. In successful projects many of the tasks a program manager assumes are handled by various people on the team; From an idea's inception to fulfillment, the development managers, project manager, architects, business analysts, developers, and any other number of people collectively undertake the responsibility of seeing the project through and adopting the tasks a program manager does, such as specifications, evangelism, scheduling, and more.
For the more analytically astute, your first question may be "What is a Program?" The American Heritage definition contains: to design a program for; schedule the activities of. Encarta's closest applicable definition is a plan of action for achieving something . Fun!
As a technical program manager, your going to be managing requirements, specs, and many other duties which will vary from organization to organization.
Simple enough, so who reports to a Program Manager? As someone (?) once joked, All the responsibility, but none of the authority! In this article, Danan Davis suggests this is 100% true, but I disagree with him 100%. While you don't have any direct reports, you must have authority. You must be a source of reliable information, with obvious knowledge and experience, and respected qualities. Authority is obtained only by the combined perception of your organization. Managing that perception is a major requirement of a program manager's job; although you probably haven't seen it listed in a role description….but that's another article.
It's true, though, that while there has been movement in some organizations to have project managers report to program managers, typically only lead or group program managers have direct reports. And their reports are other program managers.
So, who do Program Managers report to? In some organizations, program managers report to a product manager. In others, a business analyst. In other organizations program managers report (through a chain of command) to a technology officer. There seems to be growing trend in tech companies these days to less of a subject-matter expert organization chart to a more generic resource-pooled org chart, but once again that's another article.
Are you practical?
Enough about Program Manager's, what is a Practical Program Manager? I think the name for this site is best understood by the Encarta definition of practical:
1. Concerned with matters of fact
a. Concerned with actual facts and experience, not theory
2. Useful - Sensible or useful, and likely to be effective
3. Good at solving problems
a. Good at managing matters and dealing with problems and difficulties
4. Practicing - involved in the actual work of a profession or activity
a. Involved in the actual work or profession or activity.
5. Suitable for everyday use - plain, functional, and suitable for everyday use
a. Plain, functional, and suitable for every day use
6. Virtual
a. Resembling a particular thing in almost every way.
I believe those are fundamental and that the success of a Program Manager is proportional to how well he or she applies those facts. I'm sure that's true with any profession or undertaking. I do however, believe that some theory is needed in order to understand the long visions and goals of an organization. As companies constantly change, evolve and innovate, some speculation will undoubtedly be based on theory.
So, what does a Practical Program Manager wear in Jan 2006?
Something practical.
(I can submit this story to fashion magazines, now!)
Related resources:
Joal Spolsky has some history of the program manager title.
Chris Pratley's What is a program manager?
IBM has an excellent article on program management vs. project management in their rational series from developerworks.
Dave Massy: What is a program manager?
Mike deem's somewhat satirical description.
Microsoft's description.
Jobsblog has an article on PMs@Microsoft.
Wednesday, December 28. 2005
As the title says, welcome to The Practical PM!
My goal for creating this website/weblog/blog is to provide a resource for program managers to discuss…well...program management of course!
The title of "Program Manager" as it relates to software engineering is relatively new (I'll have more on that in an upcoming post.. What is a Program Manager?), and as such it's particularly hard to find material and resources dedicated solely to the program managing role.
As the saying "Don't go at it alone" holds much credence, I hope that others will also spend some time sharing their experiences, questions, and resources here. To that end, I've set up this site to allow self-registration, thereby allowing everyone the ability to put forth new subject matter. And, comments on any topic are always welcome!
I hope you enjoy!
|
