It’s nice when things work out

I've been working for the same organization for seven years now (ok – technically it won't be 7 years until next Thursday) and have gone through various positions in the company. This has provided me lots of opportunity for growth and knowledge and learning different skills.

In the last year or two I have been learning a lot about Project Management and Product Development. The thing is – I work for a company that is owned by another company and most of the projects/products I work on are fairly large with a long development life-cycle. So, I have not had the opportunities that I have been looking for to be involved in a project from start to finish.

Well, sometimes things work out and you get the opportunities you are looking for.

I started doing some beta testing in January for a company that develops various apps for the Kindle e-reader. Using my past experience with testing and a truly twisted mind, I was able to find some issues in the apps and come up with some ideas that helped the developers out. As a result, I was offered a part-time job heading up Quality Assurance/Testing for the organization and working as a Project Manager. This will be a great opportunity to see smaller projects through from start to finish to gain the experience and knowledge that I need for my career.

Check us out in the Kindle store at Amazon.com. The name of the company is 7 Dragons Inc.

Podcast Notes: Efficient Use of Meeting

From: Managing Software Development by James Edgell

The best meetings are ones that help effectively drive action. If you are having too many meetings, you need to calculate the cost of the meeting (in terms of both salary of participants and time costs of all participants for both preparation and participation). You will be surprised at how expensive a meeting can be.

Agendas and meeting notes lend toward more effective action meetings.

Agendas should have the purpose of the meeting and desired outcome stated. They should also include structured topics with time allocations. Also, a list of supporting information.

Meeting minutes should be provided post meeting. Good minutes require you to not attend every meeting and catch up if you miss the meeting. A summarization of topics discussed is provided.

After the meeting, send out the meeting minutes. Silence is acceptance. If a participant does not agree with the minutes, they should respond with a quick Reply All with correction or can be held responsible for the misunderstood item in the minutes.

Podcast Notes: A roadmap is NOT a strategy

Podcast by Alyssa Dver

The difference between vision, product strategy and product roadmap:

• Vision should be the responsibility of the top manager/management team. "This is what we want to be when we grow up."
  
• Product Strategy is very important. It should be driven by top management and needs buy in. This is the framework for achieving the vision. 1) What is the company capable of doing? 2) What are our current resources and market environment? 3) How do we think those are going to change in the future? The strategy is our way to get through foreseen changes and achieve our vision.
  
• Product Roadmap - taking the vision and strategy into consideration, here is how we are going to get there. What are the milestones and tactical expectations.
  

Example: Creation of the world

• The vision is the creation of the world.
  
• The strategy is eight divine steps. Do it in 6 days. Rest on day 7.
  
• The roadmap is creation of light on day 1, etc.

Podcast Notes: Why Product Management Is Critical

Podcast by Alyssa Dver

 

Product Managers are responsible for taking the ideas the company comes up with and matching them to the needs of the market.

Project Managers have a specific set of tasks that are related to the project.

Program Managers are usually over a set of projects.

 

Poor project/product management stems from:

• Lack of intimate customer/market knowledge
  
• Lack of clear strategy
  

Too many organizations don't take the time to talk to their actual customers. In addition, they need to talk to prospective clients and lost accounts. You need to know your market and pricing. Why are people buying/not buying your service/product instead of another company's?

Data should drive decisions. Not hopes and dreams.

Learning Goals for 2011

In 2011, I want to complete (a minimum of) the following items:

Podcasts:

• Finish listening to all Pre-2011 episodes of the 'PM411.org Project Management Podcast'
  
• Finish listening to all Pre-2011 episodes of 'The Project Management Podcast'
  
• Finish reading all Pre-2011 episodes of 'Project Management Best Practices'
  

Reading:

• Read the course binder materials for 'Fundamentals of Project Management'
  
• Read 'The Product Manager's Desk Reference'
  
• Read 'UML For the IT Business Analyst'
  
• Read 'The Rational Unified Process Made Easy'
  
• Read 'The Fast Forward MBA in Project Management'
  

 

Thoughts from “Don’t Sweat the Small Stuff at Work”

I've just finished reading "Don't Sweat the Small Stuff at Work" by Richard Carlson and wanted to post some of my favorite concepts from the book. This book is an easy read and broken down into 100 small chapters, each only 2-4 pages in length. Lots of great ideas in there and I highly recommend this and Richard Carlson's other books for motivational reading.

• Happy people are almost always the ones who love what they do. People who love what they do are highly motivated to continually better themselves and their performance.
  
• We dramatize deadlines. A lot of the stress comes not from the deadline itself, but from thinking about it, wondering whether or not we will make it, feeling sorry for ourselves and complaining.
  
• Bragging about how busy you are reinforces, to yourself, how stressed out you are. It keeps you overly focused on the most negative aspects of your work. It becomes a self-fulfilling prophecy.
  
• Tell yourself you are going to learn something new from each meeting. Search for new wisdom, new insight, or a new way of doing something.
  
• Join the TGIT (Thank God It's Today) club. Members of this club are happy to be alive; rejoice in their blessings and expect each day to be full of wonder, surprise and opportunity.
  
• Everyone loves to be acknowledged. People remember acknowledgment and appreciate it.
  
• Brighten up your work environment. You spend an enormous amount of time at work. Why not take a tiny bit of time, energy and money to brighten it up a little?
  
• Pay less attention to what other people aren't doing and put more emphasis on what you get out of your own level of productivity. It's helpful to admit that you prefer to be a highly productive individual – it's your choice.
  
• Stay focused in the now – A focused mind is more relaxed, creative, and efficient than one that is scattered. A single hour or truly focused work is a least equal in productivity to a full day of distraction.
  
• Accept the fact that, every once in a while you're going to have a really bad day.
  
• Stop scrambling. When we're scrambling we waste precious energy and make mistakes. Because we are moving so quickly, it's easy to get stressed out, nervous, and agitated.
  
• Vince Lombardi once said, "When you're doing something wrong, doing it more intensely isn't going to help."
  
• It's easy to lose sight of the fact that we thing thoughts, not reality. We begin to treat our thoughts as if they were the real thing, allowing them to stress us out.
  
• Get it over with. Do you most difficult or uncomfortable tasks first thing in the day and get them out of the way.
  
• Prevent burnout – have a life outside of work.
  

Podcast Notes: Managing Software Development - Episode #3 Defects

The Managing Software Development podcast was by James Edgell and came out in 2008. I actually found it was a useful series of podcasts and was disappointed that the series did not run for very long.

I am combining my notes from this podcast with experience I have had. For about four years, I was in charge of tracking, prioritizing, assigning and testing bugs/issues at my organization. I actually had thoughts of creating a QA team, but changes in the organizational structure and my position have led me away from focusing strictly on testing and issues. However, I still am involved in this role on a minor basis every working day.

• Defects add risk to your products but can assist in making product improvement. – No client wants to have to deal with daily defects in a product. While no product is perfect, the more defects can be eliminated, the happier the clients are. Learning from defect resolutions allows you to develop a stronger product and avoid issues in the future.
  
• Defects can tell you a lot about a team. – I agree with this, but feel even more strongly that developer responses to defects can tell you even more about a team. Having developers that are interested in making the product as strong and error free as possible enables the testing and support and business development areas of the company also work more efficiently and with less stress.
  
• Daily or weekly bug meetings help you keep on track of open defects and making sure that impact and severity levels are set correctly. – Until a product is fairly stable, keeping on top of issues and resolving them in a timely manner is critical towards keeping satisfaction with the product at a high level.
  
• Prioritize defects. – Prioritization allows the testing team and development team to focus on the most critical issues at the moment. Putting out small fires is much easier than dealing with an out of control fire in a windy, remote location. The same thing applies to defects – take them in order and get the worst fires out and keep them from growing and engulfing all the efforts of your organization.
  
• Make sure defect resolutions are thoroughly tested before rolling out to clients. – You really don't want to let a client know that an issue is resolved, only to have them call you back and state that they still see it. Taking pride in your product and your work should show and this is one of the ways to make it shine.
  
• Having a "Monitor" state for defects when a defect is intermittent or cannot be reproduced. After x number of days, status moves to terminate. – This allows developers to focus on critical issues, but also allows you to keep track of potential issues, especially if they become less intermittent. On a side note – there is nothing like finally finding a way to reproduce a pesky issue. I can testify this produces shouts of joy and happy dancing all around.
  
• Having a "Terminated" state for defects – defect is being reported, but is actually working as defined or is a duplicate.
  
• If defects are not being found – testers are not doing their job. You shouldn't be releasing until the chart of defects starts to flatten out. – Does anyone really believe they have a perfect product and that there are no issues? If so – you might want to incorporate some drug testing for your staff members.
  

We still have not found a perfect method of tracking bugs, but there are many software programs out there that will help make this process more effective. Defects are inevitable – dealing with them is critical – avoiding them is just not allowed.