Thursday May 22, 2008

In the "duh, why didn't I ask that?" category...

One of the sites that I program manage, Sun Forums, is one of the most widely used of all Sun community sites (more than 800k users who have posted nearly 4 million messages).

While the site has served as a useful communication conduit, it's had plenty of struggles -- many around community management. To help mend some fences, the core team created a "News and Updates Forum" where any of the users have direct access to the core team. Via the forum, we've taken some rightful beatings, but it's proven to be a place where we can gather amazingly rich, well thought out suggestions from our power users and a few new users -- a place where we fully open our ears, pull up our sleeves and DO SOMETHING with the feedback. We're a very small team, but we're making progress and are committed to continue to do so.

One of the downsides to the News and Updates forum is a large volume of off-topic posts. The team of users and forums core team members have implemented a few tweaks and processes to help redirect off-topic posters to a more appropriate forum. These changes have helped, but the off-topic posts continue (a few per day).

Today, one of our power users posted the following in response to an off-topic poster:
"Could you explain how you came to post your query in this topic? For some reason people keep doing this. It's a fairly obscure topic name and section, so there's a bug (real or usability related) that causes people to do this. This thread will be deleted in a minute, but if you could explain how it got here first that might be helpful."

Gee, why didn't I think to ask that? Excellent Question, Dave! :-)

Friday Sep 08, 2006

Great Meeting Ice Breaker - "Would you rather...?"

We purchased the board game "Would you rather...?" a while ago and love the concept so much that we often make up our own questions randomly. We're sometimes a corny family.

Anyway, I recently co-hosted a 2-day face-to-face planning session with people who are in different organizations, but work in a common space. One of the primary objectives of the planning session was to form critical business relationships. During the session introductions, we had each person introduce themselves then answer a "Would you rather...?" question. Examples:

Would you rather be drowned or burned to death?

Would you rather fight Mike Tyson or talk like him?

Would you rather be eaten to death by ants or or killed by a lion?

Would you rather go on a date with bad breath or body odor?

It proved to be a fun way to lighten the mood and get to know a little more about one another.

Thursday Oct 06, 2005

Inside Sun's Usability Lab...

usabilityI observed a usability study today in Sun's usability lab. Martin's group is conducting a usability study on a number of new search ideas that are being kicked around. I began program managing's search a few months ago, so I figured this was a great opportunity to not only learn more about the science of search (a LOT to learn), but also learn more about usability studies and user input on search. I've initiated a number of usability studies on various projects, but never watched them real-time.

The study consists of several one hour sessions with a single interviewer asking a single interviewee scripted questions. The types of questions depend on the type of study (branding, functionality ease of use, new concepts, etc.). In this case we are interested in gathering ease of use information for existing functionality as well as input on some new concepts that are not yet deployed.

The person conducting the interview is a non-Sun person and clearly states this to the users up front. The idea is they'll feel comfortable stating their honest opinions vs stating what they think we want to hear. She did a great job of drilling down on responses to ensure the users comments were clearly understood, but avoided influencing their opinions with repetitive or leading questions like they do in the movies until some poor sucker finally confesses to a murder s/he didn't commit.

The lab is a lot like what you see in the movies during an interrogation scene - bright room with the interviewer/interviewee on one side separated by a sound-proof one-way mirror with observers sitting in a dark room on the other side. Once I got over the "Wow this is cool! What does this do?" phase of getting familiar with the lab and began focusing on the test in-progress, I found the user responses quite interesting, surprising and at times rather humorous. For the most part, the validation of ideas was good, but I found the negative responses far more intriguing.

One of the specific points this study validated was users often abandon site navigation if search results are present. The study also validated that a few features of's search that we suspect are ambiguous are in fact so and via the study we were able to gather a few ideas on how to improve them.

Overall, observing a live usability study was an enlightening experience. It was good to observe a non-Sun person using our stuff and nice to see search meeting the expected needs for the most part.

Friday Jul 29, 2005

Smaller is Better

When it comes to web application releases, smaller is definitely better. I'm a huge fan of a monthly release cycle with routine development, code freeze, QA, UAT (user acceptance testing), and maintenance window milestones.

Aligning team efforts with monthly release milestones is usually not terribly difficult (depending on the team and application size) unless there are workflow dependencies that trump the release efforts by rightfully limiting or freezing change in development, test, production, etc. environments on an occasional or routine basis.

The trick is advanced prioritization, scheduling, and clear definition of deliverables comprising a release. Of couse, bigger deliverables have longer development & test cycles, but should still be scheduled to launch with a monthly release further out during a routine maintenance window.

Having automated regression test scripts is a must have. If feasible and possible, in addition to testing as much core functionality as possible they should also include test cases for new functionality.

Advanced reminders to the users who perform UAT and clearly documented UAT test instructions help the UAT phase run smoothly. Consistent use of a bug tracking system is also a must have.

The routine maintenance window is nice, because end users know, for example that on the last Tuesday of every month between 5-8PM PT, the system may be restarted and they may lose their session, new changes will be implemented, etc. It's also a good time to perform (non-release) infrastructure (hardware changes, OS patching, etc.) maintenance work. Although I may scheduled release deployment and infrastructure work during the same maintenance window, they usually don't happen concurrently and if possible and necessary, it's not a bad idea to run regression test scripts in between. This way, if something does go "ass up" (a borrowed phrase from one of my favorite engineers), you can isolate the suspected cause.

And of course, since monthly release cycles result in smaller more manageable releases, risk and quality issues usually are also smaller. The idea is the above benefits far outweigh the overhead required for a release.

One last point, if your environments policy, process, whatever, prevents you from delivering as frequently as is reasonable, it's time to punt the policy yourself (if you have the means and authority) or be the catalyst for change by shining the light on the disadvantage incurred as a result of not being able to delivery quickly and efficiently.

Monday Jul 11, 2005

Project Manager-Topia

In the things that make project managers overjoyed category:

1. Of course #1 is cliche, but true: Projects that deliver early, under budget AND meet or positively exceed the defined needs. Emphasizing positively (as opposed to negatively) exceeding the needs...there is a painful difference.

2. A geographically distributed engineering team. I'm feeling the benefits of this one today and tomorrow as we race against time. Thanks to all that is holy and I'm not sure how holy he is, but more specifically thanks to Chris M. (rock star engineer in the UK) and the US-based portion of the team, we're squeezing the juice out of a 17 hour (UK + US timezones) work day on a project where every minute counts.

3. And this one can be somewhat rare, but is quite common at Sun (based on my 11ish years of software development program mgt...5ish at Sun): An engineer who has SDOCD (Software Development Obsessive Complusive Disorder)...a lucky find!

Tuesday May 24, 2005

Off to PM another couple very cool programs...

My two loyal blog readers may have noticed my blogging activities have been rather abysmal lately. This is because I'm transitioning off of my current program and taking on two others.

For the last couple years I've been lucky enough to program manage Starlight ('s content management system) and be a part of a stellar team who consistently raises the delivery bar while having fun.

The two new programs that I am now lucky enough to manage are search aaaaand How lucky am I?! Here is why this is so cool:

1. I get to PM programs that I can easily and openly blog about.
2. I get to work with some rock star engineers who I've come to know by being in Will's organization, but I've never got to work with on a common program.
3. Both programs have been managed by solid program managers: DiTucci on Search and Klarissa on Blogs. So, there's already a lot of good program management stuff in place.

Woo-hoo! :-D

Thursday Feb 10, 2005

Inside the mind of a neurotic project manager...

I'm not talking about the overly certified project manager (been there, done that). I'm talking about the natural born project manager...the kind of PM that as s/he navigates a task, is scanning, scanning, scanning the surroundings for opportunities to sweep up the low hanging fruit without losing a beat on the task at hand.

Tonight...I think I've come close to my home being project manager grade utopia...the \*real\* PMs out there will gasp when they hear that statement.

I think...I have almost every personal belonging in its designated position.

That's this moment...every article of clothing that my three member family owns is either a) cleaned and stored neatly in drawers or closets or b) on one of said family members bodies.

Every small appliance, dish, pan, and utensil is clean and in it's appropriate position.

Every pet is fed and watered.

Child's homework complete and in backpack.

Child is clean and nestled comfortably in bed.

Husband: clean and watching the news on fresh linens.

Dog: nails clipped and resting at the foot of the child's bed.

Cats: ok, I don't know where the hell the cats are, but come on now...who can control cats?

Remote controls: in their easy access position.

Email: Read and responded to (both work and personal).

Cell phone: charged and ready for early morning action.

Blog: updated with a link directing traffic back to employers website.

Note to self: you're freaking me out...perhaps it's time for a vacation.

Friday Jan 21, 2005

How about this man? Do you know him?


Is this man:

a) my uncle
b) my barista
c) lead engineer on my project
d) a California Peace Officer

Thursday Jan 20, 2005

Do you know this man?


Is this man:

a) my hairdresser
b) my decorator
c) search engineer
d) a California Peace Officer

Thursday Aug 26, 2004

What do you do with a process that has too little value?

I suggest you punt it! But prior to punting a project/program process (or possibly any process), it's a good idea to 1) ask yourself if the process is implemented correctly for your project and 2) once you have validated that it is implemented correctly and still has too little value, I suggest you have a qualified colleague validate your findings prior guessed it...PUNTING IT!

Don't get me wrong...I LOVE process! But I've seen and unfortunately was tortured by the evil consequences of meaningless, valueless (is that a word?), over-process created and enforced by maniacal process radicals. My theory is if you are implementing a process (no matter how big or small), the value damn well better outweigh the cost (in terms of $, effort, time, etc.). If it doesn't, see paragraph one.

The flip side is too little process or over-simplifying your implementation of the process...which is just as bad, but don't be afraid to mold a project mgt methodology in part or whole to best meet the needs of your project. If a PM methodology is so rigid that it cannot be specifically molded to meet the needs of your specific project in a manner where the process justifies the effort, then see paragraph one.

But what if you don't have the authority to punt it? Well, sadly, you might have to live with it, but I recommend documenting the process cost -vs- process benefit data and shining a light on this collected information to the folks who have the punting authority and hopefully, this will be the catalyst for change.

Wednesday Aug 11, 2004

Cross Roadmap Planning

Managing a single project roadmap can be a real headache, but planning a combined roadmap of big projects that have many complex dependencies can quickly drive any PM insane. Many of the projects within the organization that I'm a part of have rather complex dependencies - they share infrastructure, resources, and integrated functionality to varying degrees.

Recently, we had a two day planning session that included project managers, dev managers, and architects from these various projects. Our objective was to take our eight separate four quarter project schedules and identify the cross dependencies, impacts, and milestones then figure out a combined roadmap that didn't kill anyone or anything.

stickies It sounds surprisingly simple, but we achieved our goal by iterating a roadmap with sticky notes on a wall (the image shows a small slice of the effort that survived the plane trip home). Basically we assigned each project it's own color sticky note.

Each sticky listed the:
- deliverable description
- project(s) the deliverable would impact
- task(s) required from the other team(s)
- affected resources

The stickies where then individually placed on a wall under the desired quarter in which it would deliver. Alternate categories for placing the stickies included: Low Priority/Unknown Scheduling and High Priority/Unknown Scheduling.

Once the stickies were initially placed, we discussed each one, applied necessary changes, and added the deliverables to an online roadmap. The combined roadmap includes individual project deliverables that have dependencies on other projects - not every deliverable for every project.

We'll continue to maintain the roadmap with tactical updates and continue meeting on a quarterly basis.

Other ideas on untangling cross-roadmap dependencies?

Sunday Aug 08, 2004

Why projects succeed...

All too often we read frightening articles or hear of studies on why projects fail. I thought I'd take a stab at jotting down some thoughts on why projects succeed - based purely on my own experiences with projects that both have failed miserably despite the determined efforts of myself and my teammates as well as those that I would consider a success.

Successful projects claim victory for many varying reason, but a few key common factors (complete list of success factors varies by project) that have been present in the projects I've been involved with and consider successful are (in no particular order):

1. Pure team talent
2. Clear team direction
3. Flexible yet predictable environment
4. True senior management support

Pure team talent: There's nothing I repeat nothing that comes close to influencing any effort (whether you're repairing the roof, building software, or splitting atoms) more than having the right talent involved. For the most part, the high level of competence at Sun stands second to none. Lucky for me, my current project (Starlight) has an all star line up (tho, it only took my entire 10 year PM career for the stars to align this perfectly).

Clear team direction: I've come to realize that the best laid plans (even my prettiest, well thought out roadmap) will change to some degree. It's a given that the neccesity to alter your course per unexpected, but sensible change is inevitable. This is where having a seasoned navigator comes into play...someone who can drive reasonable and timely decisions in part by effectively weighing the consequences of changing course against the anticipated yet realistic outcome. my younger PM years, I use to think I'd let my team/mgt down by asking their opinions at the confusing forks in the road...I've come to realize that this is all part of responsible decision making and more importantly that my teammates appreciate contributing decision-influencing points. The other (equally as important) half of clear team direction is (to no surprise) a solid sr. management strategy and clear stakeholder requirements/involvement.

Flexible yet predictable environment: An environment should be solid enough to stand up to the elements, but if it becomes so bullet proof, bureaucratic, and/or unreliable that effectively penetrating it with new releases requires more time and effort than the dev/test cycles, then there's something really wrong. Time to market is every bit as important as new functionality and "five nines+" (99.999 uptime). What good are the efforts behind building and testing new functionality if you can't yank it out of the oven when it's still fresh..and more importantly still critically needed?

True senior management support: Having sr. management buy-in via lip service is one thing, but having management really in the know on your project and really engaged with the project strategy and macro decision making as well as adequate funding and resourcing is a required necessity.

Wednesday Aug 04, 2004

Thoughts on PRINCE2...

If you've been doing project mgt for any length of time, you've probably thought that if you've seen one project management methodology (PMM) you've seen them all, right? That was my thought when the boss threw my current project in my lap and shipped me out for PRINCE2 (Project In Controlled Environments) training. My first thought was "Great! Another PMM with a new set of nomenclature slapped on it." perception bended a bit when one of the 1st comments out of the instructors mouth was "PRINCE2 is not meant to replace your current project protocols that work well, nor is it recommended that you implement every P2 tool with your project."

I found it rather refreshing that the P2 mantra was not "This is it! The holy grail of managing projects, people! Use this exactly as instructed and your project will never fail and you'll never die. Your projects will deliver on time and under budget. And oh...don't forget to buy our bazillion $ software products on your way out the door. Bye-bye, have a nice day." What they don't tell you is they don't use their project mgt products on their own projects because they're too cumbersome.

Instead, I've found that P2 tools have blended well with existing practices from other PMMs - such as Six Sigma (known internally as Sun Sigma), other PMM practices, & internally developed best practices. Further, I've come to appreciate the flexibility of taking specific P2 tools and molding them to meet the specific needs of the program team.

The best part of P2? The program team org structure. Here's a simple P2-based organization diagram of my project:


It places all the right people in the right position to \*really\* be engaged with the project. The program board for my project includes my VP and four of his direct reports (mostly at the director level - including my boss...who plays the role of Sr. Supplier). The project is managed by exception...meaning there are time and budget boundaries agreed to up front. Exceptions that can be managed within these boundaries require no board approval. Exceeded boundaries are escalated to the board by me (the prog mgr) w/ proposed actions. I meet w/ the program board every other week...pretty sweet deal to have that calibur of execs fully in the know on your project!

Another thing I like about the program team structure is the engagement of a project mgt team (AKA team mgrs in P2 terms)...individual Project Managers focusing on their area of expertise (as opposed to a single PM playing the role of the entire project mgt team). They report to the Program Mgr in a matrixed fashion. How many projects have you been on where 'Proj/Prog Mgr' included the roles of Dev Mgr, Quality Assurance Mgr, Business Analyst, Training Mgr, Support Mgr, Data Mgr, Sales Mgr, Marketing Mgr. etc.? Sure most small projects might get away with this model, but you're doomed for burn-out and failure if you attempt it with larger projects.

So....there's my initial 2 cents on PRINCE2...more to come...

Tuesday Aug 03, 2004

Welcome to my blog...

...for the most part you can expect me to write about program management, but there's a reasonable chance that I'll include personal thoughts and obscure humor.

I'm the Sr. Program Manager of's content management system (known internally as Starlight). I've been in the program/project mgt arena for about 10 years and at Sun for about 4 years. I can't say that as a child I dreamed of becoming a "Program Manager" but I guess it's really no surprise as a result of my maniacal drive to organize and meet deliverables.

Up next...thoughts on project mgt methodologies...


Sr. Community Engineering Program Manager/Acting Director for Sun's external social networking sites (blogs, forums, wikis, etc.). Skrocki's personal blog, LinkedIn.


« June 2016