pmStudent

Like this? Share it!

How to use Gantthead.com to find useful information quickly that is pertinent to your needs!

I'm going to ask you a question.

It's a simple question.

What is testing for?

Some people seem to think that testing is for display purposes only. These people would expect your testing phase to consist of showcasing your product instead of actually testing it.

I don't think so I think the best definition of true testing is this: Try to break the product.

That's right, the only value in testing your product is to try to poke as many holes in it as you can.

If you're testing phase consists of trying to look good in front of your customer, your stakeholders, your sponsors, then you are doing it wrong.

Get this. Earlier this week I was actually asked this question. "Next time, could we do integration testing before the official integration testing?"

That's right folks. We are talking about testing before we do testing. How sad is that?

Now let me make sure I'm clear.

We did dry run testing before the official testing. So it's not that we didn't test fully, or have ample preparation before the official testing. No, this is about looking good politically in a testing cycle.

This type of showmanship has absolutely no place in effective project management.

Period.

My teams and I do Kanban within a waterfall program.

This means that we have release cycles that start out with some investigation and detailed planning, move into true development, and then we have an Integration & Test process at the end of each release to go through.

A struggle we've had is that our value stream changes each time we transition from one phase of the waterfall cycle to another.

Furthermore, when in the Integration & Test phase, there is a specific tool we a required to use to work off what we call Test Descrepancy Reports (TDRs) which are basically bugs we find in testing.

At first, we would use a separate kanban board for the I&T phase, which maps the value stream of that process. However, due to the requirement of using a specific tool, it became a wasteful process to try and use both.  We had to keep both updated.

So in those cases, we dropped the kanban board - everything else was the same, but the visualization and mapping of a value stream went away for that portion of our work.

Has anyone else ran into a similar experience, with Kanban or something else, where a tool made a difference in terms of how you could work as a team?

Like this? Share it!

Felicia, I respectfully disagree with your instructor.

Even now while you are working on your Bachelor degree, and immediately after, I recommend you focus on gaining experience. After you have a few years of experience, you can make a better decision about what certifications or advanced degrees, if any, to pursue.

The truth is, you are much less likely to get hired as a project manager with a masters degree and no experience. You will be much better of building your experience base.

I’ve written quite a bit on how to gain experience when you are new to this field, and produced in-depth training on the topic as well.

For posts I’ve written, and please read the comments too:

http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=site%3Apmstudent.com+experience

And my my on-demand training:

http://learn.pmstudent.com/project-management-career-coaching

I hope that answer helps Felicia.

Like this? Share it!

Like this? Share it!

Thanks so much for the email Vinay, and I'm glad you enjoyed the Work Breakdown Structure book.

To answer your question, I've seen many IT projects structured that way and done it that way in the past myself, that's the norm.

However, I think there is a better way.

First, I try to avoid using SDLC/project phases as a way to structure deliverables at a high-level. There are obviously deliverables associated with phases, but in general I think doing this takes the focus away from the product and towards the process. For a scope definition document, I want it to be very much product-focused without regard for the methodology that may be used (and may change during execution).

Second, I use the levels as examples in the book and you'll probably remember my point regarding the levels at which deliverables "live" - trying to assign these levels ahead of time (a level for subsystems, another for components, etc.) is problematic. It tends to introduce artificial groupings of deliverables and levels that don't make sense. The same goes for trying to assign cost control points at an arbitrary level across the entire WBS - sometimes it makes sense to control costs higher or lower depending on the stakeholders, visibility of the element, etc.

That's probably why I went light on full-fledged end-to-end examples - no two projects are alike, and with templates people start making decisions that end up creating artificial complexity and overhead. I've been involved in several large-scale projects where this happened and we ended up with these 'phantom' levels in the WBS and requirements that just create extra work for no value. Lower-level requirements get traced through an intermediate level when they could just get traced directly to the higher level, etc. I'm talking about millions annually down the tubes just due to the structure of a WBS.

Like this? Share it!