Friday, October 2, 2009
Scope Creep - He Just Won't Leave You Alone...
Ok, this is really a space saver. I've been studying for the PMP exam and also talking to colleagues and other IT Managers in the business and began thinking about my experience and knowledge about scope creep. It's the bane of all project managers and teams as well. I found there is a difference in how scope creep generally presents itself during software development and infrastructure projects and I'll be talking about what these differences are and how to keep a lookout for them when you come across them. Allow me be your wingman and steer you clear of the scope creep! ;-)
Thursday, September 24, 2009
Not Sure How Much Confidence I Gain from this Analogy...
First, go watch the video: http://www.youtube.com/watch?v=UZq4sZz56qM&feature=rec-HM-fresh+div
Now tell me whether the idea that the welders are putting the wheels on your plane while you are in the air makes you feel confident in the company who released the jet for take-off to begin with. Me neither.
Hmmm... could this be classified as an untested beta release? Would you trust your child - or the data storage which holds your child's baby pictures - on an unfinished and untested product?
This just doesn't strike me as good marketing strategy. Just my 2c.
Now tell me whether the idea that the welders are putting the wheels on your plane while you are in the air makes you feel confident in the company who released the jet for take-off to begin with. Me neither.
Hmmm... could this be classified as an untested beta release? Would you trust your child - or the data storage which holds your child's baby pictures - on an unfinished and untested product?
This just doesn't strike me as good marketing strategy. Just my 2c.
The Courier - Microsoft's Answer to Apple's Cool Tech
Ok, I admit it! I think this looks like a great gadget that might just get added to my "must have" tech toy list:
http://gizmodo.com/5365299/courier-first-details-of-microsofts-secret-tablet
There's not much information about this product yet but it definitely appears to be a cool concept. I like the dual screen though I'm not sure about the hinges in the middle of it. I also have eyes that are older than a 20 year old's and hopefully it won't be too small for someone with my poor eyesight to read (caused by too much computer screen time, I believe...)
I saw an interview with one of the Gizmodo guys and there was a reference to the Courier as a type of electronic scrapbook. Note to people who will be marketing this toy - do not advertise it as having to do anything with scrapbooking or "scrapping" as people who are into this bizarre hobby refer to it. (You know there's a subculture involved when a noun - scrapbook - is shortened and used as a verb or gerund). I like technology! Give me a toy with lots of buttons, beeps, and flashy slash screens and liken it to something cooler than a scrapbook, please!!! :-)
http://g4tv.com/attackoftheshow/theloop/68515/First-Details-on-Microsofts-Courier-Tablet.html
Ok, so there's not a lot of information beyond Gizmodo's initial video clip scoop about what a user can do with it. The capabilities seem to be more in line with a day planner on steriods and I can definitely see some real applications of using this tool while working on projects. I can't wait to see what capabilities the Courier will have to tie it into some of Microsoft's office tools. As a PM, being able to tie a portable day planner/tablet into sharepoint or other PMIS could ultimately be a real win since blackberries are too small to do anything more than email and laptops can be a real drag to carry around.
I look forward to learning more about the Courier. If Microsoft would like a field tester, I volunteer!
http://gizmodo.com/5365299/courier-first-details-of-microsofts-secret-tablet
There's not much information about this product yet but it definitely appears to be a cool concept. I like the dual screen though I'm not sure about the hinges in the middle of it. I also have eyes that are older than a 20 year old's and hopefully it won't be too small for someone with my poor eyesight to read (caused by too much computer screen time, I believe...)
I saw an interview with one of the Gizmodo guys and there was a reference to the Courier as a type of electronic scrapbook. Note to people who will be marketing this toy - do not advertise it as having to do anything with scrapbooking or "scrapping" as people who are into this bizarre hobby refer to it. (You know there's a subculture involved when a noun - scrapbook - is shortened and used as a verb or gerund). I like technology! Give me a toy with lots of buttons, beeps, and flashy slash screens and liken it to something cooler than a scrapbook, please!!! :-)
http://g4tv.com/attackoftheshow/theloop/68515/First-Details-on-Microsofts-Courier-Tablet.html
Ok, so there's not a lot of information beyond Gizmodo's initial video clip scoop about what a user can do with it. The capabilities seem to be more in line with a day planner on steriods and I can definitely see some real applications of using this tool while working on projects. I can't wait to see what capabilities the Courier will have to tie it into some of Microsoft's office tools. As a PM, being able to tie a portable day planner/tablet into sharepoint or other PMIS could ultimately be a real win since blackberries are too small to do anything more than email and laptops can be a real drag to carry around.
I look forward to learning more about the Courier. If Microsoft would like a field tester, I volunteer!
Thursday, September 17, 2009
Agile vs. Waterfall: A Personal View
Ok, before the town halls start and people start screaming about what their favorite software development methodology is while drowning out the opposition, let me say that I do not believe that one is necessarily better than the other. Let's face it - if this was a perfect world, no methodology would have to exist. Programmers would hear and understand the request from the customer immediately and quickly crank out the perfect software application in response to the request. Now we come to the real world and we all know this will rarely, if ever, happen. (if it has, please tell me about it!) This would also put Project Managers out of work.
Recently, I engaged in a discussion with a colleague regarding the Agile vs. Waterfall methodologies and came upon what I like to call The Agile Wall. According to this colleague, there is nothing good about Waterfall. If it isn't Agile, it's crap. And so on. I've encountered this before and it shouldn't surprise me any more but I do think Waterfall has it's place. Now before you go yelling your head off, hear me out...
There is a time and place for everything. In my opinion, it is important not to blindly adhere to a single methodology without taking in a comprehensive view of a new project. Each project is different and there are many factors which should be taken into consideration before defining the process to be applied.
Here is a high level diagram of how complexity of the project should be considered when choosing which methodology will be the correct choice for a project. The problem of this picture is that there are projects that are landing in the "High Complexity" range which do not react well with Agile methodology and end up with poor results. By the same token, a low complexity project which has been bogged down in a Waterfall will probably be just as problematic. The sweet spot for managing a development project is ensuring that complexity is reduced by creating phases and sub-tasks, and applying a hybrid methodology to address development which is beyond the ability for a pure Agile methodology to address.
The real trick is finding the right mix. Agile is a fantastic methodology for very small, low complexity projects, especially when working with small teams. When the project grows to be something more than that, with more stakeholders and more requirements which may be codependent on one another, the advanced legwork of requirements gathering can really end up saving time over the long haul. However, breaking those complexities down into smaller chunks that can be applied in an Agile method can be done to save time and effort overall.
Waterfall can be time consuming and can seem like a waste of time. However, a complex environment can sometimes benefit from a good solid design effort up front. There is also a lot less likelihood of "cowboy coding" resulting in spaghetti code that has been churned out via Agile and Extreme methodologies (have you ever tried debugging some of this stuff??? Ugh!)
So, my advice is that at the beginning of the project, stand back and take a good look at what is to be accomplished. Weigh the triple constraints (scope, time, budget) against the complexity of the project, know your expert teams, and be realistic. Reduce your complexity and apply the methodology to your project, not the other way around. In the long run, you'll be glad you did.
Recently, I engaged in a discussion with a colleague regarding the Agile vs. Waterfall methodologies and came upon what I like to call The Agile Wall. According to this colleague, there is nothing good about Waterfall. If it isn't Agile, it's crap. And so on. I've encountered this before and it shouldn't surprise me any more but I do think Waterfall has it's place. Now before you go yelling your head off, hear me out...
There is a time and place for everything. In my opinion, it is important not to blindly adhere to a single methodology without taking in a comprehensive view of a new project. Each project is different and there are many factors which should be taken into consideration before defining the process to be applied.
Here is a high level diagram of how complexity of the project should be considered when choosing which methodology will be the correct choice for a project. The problem of this picture is that there are projects that are landing in the "High Complexity" range which do not react well with Agile methodology and end up with poor results. By the same token, a low complexity project which has been bogged down in a Waterfall will probably be just as problematic. The sweet spot for managing a development project is ensuring that complexity is reduced by creating phases and sub-tasks, and applying a hybrid methodology to address development which is beyond the ability for a pure Agile methodology to address.
The real trick is finding the right mix. Agile is a fantastic methodology for very small, low complexity projects, especially when working with small teams. When the project grows to be something more than that, with more stakeholders and more requirements which may be codependent on one another, the advanced legwork of requirements gathering can really end up saving time over the long haul. However, breaking those complexities down into smaller chunks that can be applied in an Agile method can be done to save time and effort overall.
Waterfall can be time consuming and can seem like a waste of time. However, a complex environment can sometimes benefit from a good solid design effort up front. There is also a lot less likelihood of "cowboy coding" resulting in spaghetti code that has been churned out via Agile and Extreme methodologies (have you ever tried debugging some of this stuff??? Ugh!)
So, my advice is that at the beginning of the project, stand back and take a good look at what is to be accomplished. Weigh the triple constraints (scope, time, budget) against the complexity of the project, know your expert teams, and be realistic. Reduce your complexity and apply the methodology to your project, not the other way around. In the long run, you'll be glad you did.
Sunday, September 13, 2009
My Thoughts on the PMP Exam Review
I'm really excited about the weekend review seminar I'm taking for the PMP exam. Like anything, I questioned whether the value would be worth the expense by doing my own personal cost benefit analysis (yes, I apply these concepts to my personal life as well.... :-) So far, I like what I'm seeing. I've read the PMBOK (both 3rd & 4th editions) and have been applying the PMI methodology in my work for years. The intent of the class is not teaching project management, but focusing on passing the exam. This is exactly what I needed. I was a bit worried that it was going to be a PM 101 course but instead it's focused on helping experienced PMs focus on the exam. We are using the Crosswinds class materials (about 50 lbs of books, cds, flash cards, etc) and in addition to the presenters, it appears to be a great value add to my studying.
I also had a great time meeting new people and engaged in some very interesting side conversations with other PMs with similar experience in software development. One of the most interesting conversations related to the Agile vs. Waterfall methodologies used in SDLC. I anticipate that I will go into more detail about this in my next post, but right now I need to go study and do my 'homework'.
I also had a great time meeting new people and engaged in some very interesting side conversations with other PMs with similar experience in software development. One of the most interesting conversations related to the Agile vs. Waterfall methodologies used in SDLC. I anticipate that I will go into more detail about this in my next post, but right now I need to go study and do my 'homework'.
Friday, September 11, 2009
PMP Exam Review Seminar Begins Tomorrow!!!
I'm looking forward to attending the review class for the PMP certification exam. I did most of my previous studying on PMI's 3rd edition of the PMBOK so I can really use the refresher in addition to going over the 4th edition modifications to the guide.
The seminar is taking place for the next 6 Saturdays (yeah, I know...) but it will be worth it. I'm looking forward to meeting fellow students studying for their exams and hoping to do a little networking as well. My goal is to take the exam no later than November. I keep kicking myself that I didn't do this last year but I was so busy I just didn't have the opportunity to really dig into the material like I wanted to.
Wish me luck...8am on a Saturday, I'll need it! :-)
The seminar is taking place for the next 6 Saturdays (yeah, I know...) but it will be worth it. I'm looking forward to meeting fellow students studying for their exams and hoping to do a little networking as well. My goal is to take the exam no later than November. I keep kicking myself that I didn't do this last year but I was so busy I just didn't have the opportunity to really dig into the material like I wanted to.
Wish me luck...8am on a Saturday, I'll need it! :-)
Wikis and Blogs - PMI Houston West Side Meeting Yesterday
I went to PMI Houston's west side meeting yesterday and sat in on a discussion about using social networking behind the firewall. Naturally, the discussion centered around using Sharepoint 2007. I've worked in organizations that have had some type of interactive forums (usually technical) and usually some type of shared employee contact and calendar functionality. In my experience, I've only used Sharepoint for it's document repository features so this discussion piqued my interest.
The presenters, Micheline Duguay and Roslyn Metchis from Obsidian, talked about how most audiences will be broken out into generic groups: baby boomers, gen x, and gen y. The general comfort level with the new tools related to gadgets and social networking varies greatly between the groups, with the people having the most knowledge using the technology the least. Gen Y, however, is most likely to jump on the bandwagon and join the social networking sites set up behind the firewall.
I'm very curious if there is a way to quantify the value of a tool like this? Facebook and Myspace can be big time wasters and I'm curious if anything similar has been found within the firewall as well. I think of the youngsters I know who are much more comfortable txting and facebooking than in a face to face meeting and wonder what the real impact of these tools really is as well as what their full potential might be.
I love the idea of having these tools in place and in most environments I can only imagine them to be a value add. However, I would like to find out how these tools really play into managing a project. How much time should be allocated in a project for blogging, for instance? Should it be considered? Does it replace other types of documentation?
I've had to crack the whip (figuratively!) on getting my developers to document, but at the same time I know the majority of them contribute regularly to online technical forums and communities. Having a nice hybrid in place to capture more of their knowledge behind the firewall seems to make a lot of sense. I can see that it would have to be carefully managed, however, to prevent too much non-relevant information from creeping into the documentation and ensure that project teams keep to the path, so to speak. Best practices for an organization would need to be in place for this type of effort over the long term.
I look forward to working with this technology as soon as I get a chance. I can see where this could be a real benefit in a technical environment!
The presenters, Micheline Duguay and Roslyn Metchis from Obsidian, talked about how most audiences will be broken out into generic groups: baby boomers, gen x, and gen y. The general comfort level with the new tools related to gadgets and social networking varies greatly between the groups, with the people having the most knowledge using the technology the least. Gen Y, however, is most likely to jump on the bandwagon and join the social networking sites set up behind the firewall.
I'm very curious if there is a way to quantify the value of a tool like this? Facebook and Myspace can be big time wasters and I'm curious if anything similar has been found within the firewall as well. I think of the youngsters I know who are much more comfortable txting and facebooking than in a face to face meeting and wonder what the real impact of these tools really is as well as what their full potential might be.
I love the idea of having these tools in place and in most environments I can only imagine them to be a value add. However, I would like to find out how these tools really play into managing a project. How much time should be allocated in a project for blogging, for instance? Should it be considered? Does it replace other types of documentation?
I've had to crack the whip (figuratively!) on getting my developers to document, but at the same time I know the majority of them contribute regularly to online technical forums and communities. Having a nice hybrid in place to capture more of their knowledge behind the firewall seems to make a lot of sense. I can see that it would have to be carefully managed, however, to prevent too much non-relevant information from creeping into the documentation and ensure that project teams keep to the path, so to speak. Best practices for an organization would need to be in place for this type of effort over the long term.
I look forward to working with this technology as soon as I get a chance. I can see where this could be a real benefit in a technical environment!
Thursday, September 10, 2009
Updating Blog - I Appreciate Your Patience
Due to technical issues outside of my control, I've been forced to move my blog. I am currently in the process of moving the tidbits that are worth moving to their new home on the web! I'll only bring that which could be deemed worthy, and will leave the rest behind. The new blog will be all about moving forward and constant improvement!
Keep checking in for my latest nuggets of knowledge!
Keep checking in for my latest nuggets of knowledge!
Tuesday, September 8, 2009
Keep It Simple and Communicate!!!
Having worked in the IT industry now for about 15 years, starting as a developer and most recently as a manager, I have to say that this little snippet from Youtube summarizes the issues and risks better than any 300+ page book I've read to date.
http://www.youtube.com/watch?v=OfgfnZZdMlI
This definitely applies the KISS principal to describing the potential pitfalls encountered with many stakeholders involved in a development project. Well done!
http://www.youtube.com/watch?v=OfgfnZZdMlI
This definitely applies the KISS principal to describing the potential pitfalls encountered with many stakeholders involved in a development project. Well done!
Subscribe to:
Posts (Atom)