Thursday, June 28, 2007

No Task Longer Than 80 Hours and Not Shorter Than 40

Raven points me to some interest truths of Projects. I actually I prefer tasks that are no longer the 40 hrs and no shorter then 20 hrs.
 
Kinda 1 work of 1/2 a work week seems ok with me.
 
"So treat your people right and remember to focus on your soft/interpersonal skills and you'll be more successful as a project manager" - totally agreed Raven !!

Friday, June 15, 2007

death by meetings

Randy recaps the pain point of org meetings !!
 
"Most every meeting in every company that I've worked for is scheduled in the hours before or the day before the meeting actually takes place. Quite often, attendees don't show, because they are unaware of the meeting or had previous commitments. This leads to meetings which start one half hour to an hour late, as attendees are rounded up. This means that several people are sitting around for up to an hour with better things to do. Sometimes, key attendees don't show and the meeting turns into a complete waste of everybody's time. All meetings (except emergencies) can easily be scheduled with 2 business days of notice, thus giving all employees adequate time to reschedule and prepare for the meeting. If you improperly organize a meeting where 8 people waste one hour, then you've effectively wasted an entire man-day of work. In other words, had you just stayed home that entire day and not wasted those 8 people's time, then your company would be no worse off."
 

Thursday, June 14, 2007

estimation blues


"Accuracy of estimation is directly related to the parameters you consider in estimations "
 
Rajesh actually nails that pretty well in his posting !!
 
I would also like to add, that most PM forgot the talent management aspect during estimation. How much of time do I need spend to convert "a resource" and obtain a buying during project execution. Normally resources are thrown in and then management of these resources are based on time/cost parameters and hardly any consideration is given to the fact that one needs to develop the resource towards the ultimate goal of the the project and vision statement of the project. 
 
Keeping talent development as a parameter fosters a culture of growth on every project. Thus leveraging the business Mission on the long run. And, that's strategy execution alongside projects :)-

Something to think about

The idea is that software development lifecycle events have import, not only to project management, but change management of the IT infrastructure as well.

There's a new Visual Studio Team System (VSTS) offering with Microsoft Project Server !!

 

Wednesday, June 13, 2007

Working the 20 somethings !!

It could become a little tricky when dealing with new age talent !!

"Nearly every businessperson over 30 has done it: sat in his office after a staff meeting and - reflecting upon the 25-year-old colleague with two tattoos, a piercing, no watch and a shameless propensity for chatting up the boss - wondered, What is with that guy?!"

This is a must read article for all Project Manager's who factor in talent capital  across multiple countries, cultures  !!

--
Peter Dawson
http://peterdawson.typepad.com
PeterDawson Home of ThoughtFlickr's
"This message is printed on Recycled Electrons."
R : 905 270 2025
C : 416 689 7383
E : slash.pd@gmail.com
Skype: Slash.pd

MSFT Escrum v1.0


 Kewll..need to play with this !! :)-

"eScrum is a Web-based, end-to-end project management tool for Scrum built on the Microsoft Visual Studio Team Foundation Server platform. It provides multiple ways to interact with your Scrum project: eScrum Web-based UI, Team Explorer, and Excel or Project, via Team Foundation Office Integration. In addition, it provides a single place for all Scrum artifacts such as product backlog, sprint backlog, task management, retrospective, and reports with built-in context sensitive help"

Download available here and Steve has more info

Tuesday, June 12, 2007

project rules ( simple version )


In his recent IEEE Software column, "Ship Effortlessly" J.B. Rainsberger has a gem:

I start each project with two rules: all source files must be in a version control repository, and the build must be fully automated at all times.

Does your project follow these rules? If not, what would you have to do?

How do you get a team to develop a clear and elevating goal?

The truth is, I don't know for sure. No one does. If we did, we'd be mass-producing winning teams instead of writing about them. But here's my 2 cents worth
 
1. First and foremost, a team's clear and elevating goal as described above is never the goal you gave it.
That's your goal, not theirs. To the team, it's a task, a project, or an assignment. What's the difference? One is inherently motivating; the other isn't. One is something for which the team is willing to take 100% responsibility; the other is something you will hold it accountable for.
2. There is no recipe or formula you can apply to a team that will result in a clear and elevating goal each time.
The highest-leverage activity a leader can accomplish is to catalyze a team around a clear and elevating goal. If I could bottle that skill and develop it in leaders, I'd be running a skill-building production facility (and you'd be in line!). But that doesn't mean it has to be a random happenstance. It means that crafting a clear and elevating goal is a design issue rather than a formulaic process. And what you are designing is a set of conditions that encourages a team to explore what it wants (rather than what its employers want).
3. There is, however, a set of initial conditions that you can design and influence.
Unfortunately, while most leaders would kill for teams with clear and elevating goals, what they are killing are the conditions that support them. The single most important variable I've discovered is that the team's larger operating environment supports the team in thinking about what it wants out of a project the team has been assigned to. Organizations have a way of systematically extinguishing the wants of team members, while simultaneously calling for passion and commitment. We tell people what they should want. We tell them our goals and our parameters and then we tell them to get busy. As I ask folks on client sites what they want out of a project, more frequently than not I hear "Gee, no one's ever asked me that before."

The leader who understands clear and elevating goals will invest in creating a culture of responsible leadership that acknowledges intrinsic motivations and supports personal freedom and choice. Then, he or she will make room in projects for team start-up processes that truly engender ownership within the team for the project.

4. You can challenge the team to discover such a goal and even invest time in that discovery process.
Ttreat the clear and elevating goal as one of five conversations a team must have (in fact, that a high-performance team will naturally engage in). But it's not the first conversation I would encourage; it's the fourth. There are three other things I would do first to give the team the best chance of reaching high performance.
 
5. It's always a nonlinear process, a lateral-thinking process, and a surprising result
Most leaders make the mistake of challenging teams to "choose a number," meaning setting as its goal a performance metric for the business, project, or technology. That's frequently misplaced MBA-speak. Clear and elevating goals are usually qualitatively different than the assigned task while beautifully supporting the task getting done. For instance, a team assigned to launch an Internet banking service created the slogan "we're reinventing banking" and envisioned itself on the cover of its industry's trade journal. The team designed hotel-like hangers for its doorknobs that said "Do Not Disturb. Busy reinventing banking."
 
6. It usually happens coincident with breaking through conflict
Clear and elevating goals seldom emerge until well into the project. In the forming-storming-norming-performing metaphor of team development, I've found that the storming phase is often resolved by the emergence of a clear and elevating goal, which then guides the norming and performing phases. You can support this process by helping the team develop healthy ways to disagree and stay committed to each other as a team.
 
Hattip :  Christopher M. Avery, Senior Consultant, Cutter Consortium

 

project Leadership

Nice read here

--
Peter Dawson
http://peterdawson.typepad.com
PeterDawson Home of ThoughtFlickr's
"This message is printed on Recycled Electrons."
R : 905 270 2025
C : 416 689 7383
E : slash.pd@gmail.com
Skype: Slash.pd