its true

Ye kitabon k qisse ye fasano ki batein,
Nigahon ki jhilmil ye judai ki ratein,
Muhabbat ki kasmein nibhane k wadey,
Ye wafa ka dhoka ye jhote irade,
Ye batein kitabi ye nazmein purani,
Na inki haqeeqat Na inki kahani,
Na likhna inhein Na mahfooz karma,
Ye jazbaat hain bus inhein mehsoos karma…..

I love

Affirmation Poem/Song
Harry Nagel ©2007
Greensboro, North Carolina

I love myself and how I live
each and every day
I love myself and share that love
in my work and play

I love myself and so forgive
and know that I am free
I love myself and so I live
for now, eternally

I love myself and everyone
I meet along the way
And like a mirror they return
that love to me each day

I love myself as I am
the way God created me
I love myself and I affirm
the way I want to be

I love myself and I affirm
the way I want to be

TimeLine: Getting and Keeping Control over your Project"

Very interesting/informative and good document.

booklet: "TimeLine: Getting and Keeping Control over your Project"
URL: (www.malotaux.nl/nrm/pdf/TimeLine.pdf).

The TimeLine technique can be used for controlling any span of time: Programs, Projects, Sub-projects, DeliveryCycles,

weekly TaskCycles and even single Tasks.

busy in designing

so what i did last month?

Nothing nothing and nothing,

ohh nooooOooO

I was busy in graphic designing.

and i read one novel. that i like the most. "Piyar Ka Pehla Shehar"

now a days i am also busy reading few books, nd novels.

these are not good days for me.

............................................................................ confused because of my life (present/future) little bit.

but i really don't want.

Well i am the best, i know. sometimes i'm not good, i know this too.

want to happy forever.

im here again,after a long time

How can I stay happy when I'm going through a
really bad times??


aaty hen, chaly jaty han,
jany waly kabhi kabhi yahan apny pyar sy
logo k dilo me yad gar ban jaty hen.

rona na, udas hona na, ye anso khona na
yahan na damin bhigona kabhi
pana ha, kabhi kuch khona ha
yahn jo hona ha ho ga wahe

yahe zindagi ha yahan jiye wahi log jo
sary gham bhula k ansoun me muskuraty han


chalna ha humen to chalna ha
akaly chalna ha, koi b ho ya na ho hamsafar,
raho me, ruky ya hum chalyn,
kahi b rukta nahi ye safar,

ana jaana laga rahy, jevan ki raho me,
rahen wai rehti han, rahi badal jaty hen

rato k, andheri rato k, ghanery sayiey me
chupa to ho ga sawera kahin
ayeiy ga sawera ayiey ga, ujaly layey ga,
andhery hon sy humesha nahi,
many na jo har kabhi ksi hal me,
wahi yahan phool kbhi kanto me khilaty hen

every work can not be easy-> Mirza Ghalib

1.      bus ki dushwaar hai har kaam ka aasaaN hona
        aadmee ko bhee muyassar naheeN  insaaN hona

        [ dushwaar = difficult, muyassar = possible ]

2.      giriya chaahe hai KHaraabee mere kaashaane ki
        dar-o-deevaar se  Tapke  hai bayaabaaN   hona

        [ giriyaaN = weeping, kaashaana = house, bayaabaaN = wilderness ]

3.      waa-e-deewaangee-e-shauq, ke har dam mujhko
        aap jaana udhar aur aap  hee  hairaaN  hona

4.      jalva  az_bas  ki taqaaza-e-nigah  karta hai
        jauhar-e-aaina bhee chaahe hai mizhgaaN hona

        [ az = from/then/by, jauhar = skill/knowledge, mizhgaaN = eyelid ]

5.      ishrat-e-qatl_gah-e-'ehl-e-tamanna  mat pooch
        id-e-nazzaara  hai shamsheer  ka uriyaaN hona

        [ ishrat = joy/delight, shamsheer = sword, uriyaaN = naked/bare ]

6.      le gaye KHaak meiN ham daaGH-e-tamanna-e-nishaat
        too  ho  aur  aap  ba_sad_rang-e-gulistaaN  hona

        [ nishaat (or nashaat) = enthusiasm/happiness, sad_rang = hundred
          colours ]

7.      ishrat-e-paara-e-dil,  zaKHm-e-tamanna_KHaana
        lazzat-e-reesh-e-jigar GHarq-e-namakdaaN hona

        [ ishrat = joy/delight, paara = fragment/piece, lazzat = taste,
          reesh = wound, GHarq = drown/sink, namakdaaN = container to
          keep salt ]

8.      kee mere qatl ke baad usne jafa se tauba
        haay us zood_pashemaaN ka pashemaaN hona

        [ jafa = oppression, zood = quickly, pashemaaN = ashamed/
          embarrassed ]

9.      haif  us chaar girah kapDe  ki qismat 'GHalib'
        jis ki qismat meiN ho aashiq ka girebaaN hona

        [ haif = alas!, girah = one sixteenth of a yard, girebaaN = collar ]

Real Project Teams Bring Real Project Success

Ever wonder what happened to management's commitment to growing and fostering winning teams?  Why it is that today, CEOs and CIOs are reducing their investment in team-building.  Are teams another casualty of over-exuberant cost control or a reflection of management's attitude that talent is just another plug-and-play commodity?  Is there a connection between sustainable success in delivering IT projects and tight and cohesive teams?

<SCRIPT language='JavaScript1.1' SRC="http://ad.doubleclick.net/adj/N815.ibmganthead/B2802818;abr=!ie;sz=336x280;ord=04230534?"> </SCRIPT> <NOSCRIPT> <A HREF="http://ad.doubleclick.net/jump/N815.ibmganthead/B2802818;abr=!ie4;abr=!ie5;sz=336x280;ord=04230534?"> <IMG SRC="http://ad.doubleclick.net/ad/N815.ibmganthead/B2802818;abr=!ie4;abr=!ie5;sz=336x280;ord=04230534?" BORDER=0 WIDTH=336 HEIGHT=280 ALT="Click Here"></A> </NOSCRIPT>

In my experience, part of the formula for delivering incredible value on IT-centric projects is the quality of the team doing the work.  Unfortunately, it seems that more and more projects are resourced using a talent pool concept where people are thrown together based on credentials without much regard as to their collective chemistry, which in turn does little to foster a winning team environment.  Once the project is over, the players go on their merry way perhaps never to work together again.  Thus, there is little emotional connection to the project, little or no buy-in by the "team" to the project or each other; in short no investment other than just performing assigned tasks.  Is it any wonder that project costs are increasing and project successes decreasing?  Imagine any sport where at each game a team was assembled based on talent (like all-star games) and not based on their ability to work as a unit towards a common goal: winning.  Just like in the all-star games the quality of play usually is poor and the effort put out equally as unimpressive.

What's needed is a return to the premise that fielding a team that works together as a unit over the life of many projects will more than pay for itself in short order.  Great teams take time to gel.  They need to build inner trust and rapport in such a way that they don't second guess each other; they defer to each other's expertise level, while watching each other's backs.

Unfortunately, for most organizations permanent teams are seen as expensive and inefficient because they can't be deployed as a unit on a full-time basis.  The problem is that teams are measured based on FTE's utilized and not by the results achieved.  Using an FTE approach to justify the team, I guess we wouldn't have SWAT Teams, Fire Departments or Special Forces.  This blind spot among executives has most likely cost billions in true productivity; the kind of productivity that actually produces breakthrough outcomes.

So what can be done to build teams that can stay together over extended periods of time?  First, management can create teams that come together for projects but also perform other staff level duties when project demand is low.  Examples of these duties would include training, research, testing and implementation reviews.  The idea is to have the team members active but on call when a project surfaces.

Next, organizations can organize their project portfolios in such a way that optimizes dedicated team efforts.  In this way, a team could work on simultaneous projects as a team allowing them to move between the projects in order to keep them fully deployed.  Two to three projects, somewhat staggered as to phase, can usually occupy a five person team full time.
Finally, management can create a Macro Team Pool comprising people whose talents and personalities complement each other and then rotate them in and out of projects in a way that builds and sustains the macro team's rapport while allowing flexibility on team staffing.

The goal is to create a cadre of IT and project professionals that work well in a team environment in a way that builds an ongoing sense of belonging and accomplishment.  In doing so the organization can enjoy accelerated project results, improved retention of talent and superior project ROI.

Sometimes great teams happen by accident but more likely than not they are the result of purposeful planning and orchestration by management.  The catch is that management needs to see the value in the team proposition and be willing to invest in the building and nurturing process.

Do closely knit teams make a difference to project success?  There can be no doubt that they do.  One case in point can be found at GE Business Information Center (GEBIC).  As recently retired John Wilfore, head of GEBIC recounts:
"GEBIC services were unique because of the commitment to empowered and self-directed work teams.  These teams significantly increased cost-based productivity by 106% and increased customer satisfaction from 93% to 99.4%."  (Source - http://www.callcentres.com.au/GEBICteams.htm)

Creating winning self-directed project and work teams isn't rocket science but it does take commitment, patience and vision.  In the end, the organizations with the best teams will win.Michael Wood

Project Team Meeting Evaluation Form

Instructions

Indicate by circling the appropriate number (1 is low; 7 is high) your assessment of the meeting.

Date of Meeting:
Purpose of the Meeting: Totally befuddled as to the purpose or objective of this meeting.	1 2 3 4 5 6 7	The purpose or objective of the meeting was well defined.
What We Wanted to Achieve: By the end of the meeting, we didn’t have the foggiest notion of what we wanted to achieve.	1 2 3 4 5 6 7	We decided what we wanted to achieve by the end of the meeting.
Meeting Preparation: We were completely unprepared for this meeting.	1 2 3 4 5 6 7	We were sufficiently prepared for the meeting.
Meeting Effectiveness: Information was disconnected and disjointed. Tangent discussions.	1 2 3 4 5 6 7	Good flow of information. Focused presentation and discussion.
Team Participation: Little or no team participation in discussions.	1 2 3 4 5 6 7	Team actively participated in the meeting.
Ground Rules: We violated many, if not all, of our ground rules during the meeting.	1 2 3 4 5 6 7	We lived by our ground rules.
Meeting Process: Meeting started/finished late. Attendance was poor or incomplete.	1 2 3 4 5 6 7	Meeting started and ended on time. Attendance was good.
Time Allocation: Agenda items continually ran over allotted times.	1 2 3 4 5 6 7	Agenda items were addressed in the times allotted for them.
Meeting Usefulness: A total waste of time.	1 2 3 4 5 6 7	The meeting was an effective use of my time.
Teambuilding: The meeting was a chore, and the atmosphere sucked.	1 2 3 4 5 6 7	We had fun and got something accomplished.

From Agile Development to New Software Engineering

In 1997, long before agile project management became a buzzword, a paper was presented at a military software conference, entitled “Disciplines Delivering Success” [1]. I find it sobering to read that paper 10 years later and see how little our organizations have advanced over the decades. Brown presented six “project-saving disciplines ignored by management”:

• Good personnel practices


• Planning and tracking using activity networks and earned value


• Incremental release build plan


• Formal configuration management


• Test planning and project stability


• Metrics

It is sobering because those are very similar to the starting recommendations offered by agilists today. Clearly we agilists are not unique in requesting these items--good project managers have been requesting them (and getting ignored) for a long time. I show that list so that we don’t have to re-hash the past yet again. I assume you will take of those things.

More interesting than rehashing the past is deciding how to move forward. To this end I present how software engineering is being revised to take account of what has been learned in the agile movement. It indicates where we should put our attention in the next decade.

Leaving aside navel-gazing questions concerning the definition of the term “software engineering,” but getting straight to the point, the new variety of software engineering is built on three legs:

• Craft


• Cooperative gaming


• Lessons from lean manufacturing

Craft

Doing a bit of research [2], I found that the term “engineering” prior to the World War II-contained elements of craft, both in field practice and in academia. During the war, applied physicists amazed everyone with what they could do, with the result that engineering academia started emphasizing the mathematical aspects of engineering rather than the craft aspects.

We are seeing renewed attention to the craft aspects of our profession. Being in a craft profession brings with it certain expectations, such as lifelong learning, or “deepening” the proficiency in one’s craft. Programmers shouldn’t think that just because they once learned to program a computer, their programming skills are still sufficient. Craft professionals, programmers, project managers and others should always be looking to learn new tools and techniques, and get better in the ones they have.

In software development, we can immediately name seven craft specialties:

• Deciding what to build


• Modeling


• Managing the people and the project


• External design


• Large-scale design (architecture)


• Fine-scale design (programming)


• Verification and validation

In other disciplines, the technical craft set will vary, but managing the people and the project remain. For project management, it should mean that people are not simply assigned to project management positions from off the street or out of their programming cubicle, but rather they enter the position in recognition that they are at the starting stage of a new craft and skill set.

At the moment, what concerns us is that people are not interchangeable, nor are skill sets. Each involves life-long learning.

Cooperative Gaming

When people develop software, they are working to understand a problem that they don’t fully understand, and which keeps changing underneath them. They are inventing a solution that they don’t fully understand and which keeps changing underneath them. They are forced to use contrived languages that they don’t fully understand, and which keep changing underneath them. Each person is making decisions, each decision causes a ripple of economic consequences--and the project is economically constrained.

To rephrase that in a pithier way, software development is a cooperative game whose purpose is to deliver working software. The moves in that game are only to invent and to communicate to other people and to the computer.

Considering software development an economically constrained cooperative game of invention and communication helps us understand project management. It highlights that:

• Every game and every situation are potentially different--there is no formula for winning the game. Different, even opposite strategies may be needed at any instant.


• The quality of a move in the game is not absolute, but rather is only relative to how it improves the position of the team for its next move.


• The quality of community and communication among the team members matter enormously--they often make the difference between success and failure.

These lessons are immensely valuable for the project manager. Rather than pushing for “complete requirements” or a “complete design”, the project manager should be asking, “How many requirements, and at what quality level, do we need now so that we can get to a good position for our next move, considering the time and resource constraints we have on us at this point?”

The answer to that question varies by project and even by moment in a project. Sometimes, the answer is “relatively complete” (for fixed-price contracts). Sometimes it is “just a few, medium quality” (for certain internally funded projects); at other times it is anything in between. The same question applies to completeness and quality of the different elements of the design, of testing, of the project plan itself.

The cooperative game idea also highlights the importance of people, their talents, their skills and their interactions. Their interactions are important because people at odds with each other withhold information. Every piece of information not exchanged costs the project lost time.

In capsule form, the speed of the project is limited by the speed at which information flows between people. Everything that slows the movement of ideas between people slows the project!  Bad attitudes slow projects, distance slows projects and certain communication tools help more than others. This is why agile developers have their own preferred communication tools [3] (for example, information radiators [4]).

The cooperative gaming lexicon is rich, and I will draw more from it in the next column.

Lean Manufacturing

It is not immediately apparent that manufacturing has anything in common with software development. Manufacturing is all about making the same thing over and over, while software development is all about making something different each time.

If, however, we consider decisions as the thought-worker’s version of parts inventory, then suddenly we see that people hand other people decisions, people wait on each other for decisions, and some people have a bigger backlog of decisions than they can handle at the moment. Examining the dependency network of decisions in play in an organization, we see that this network is very similar to the dependency network of parts in a manufacturing plant. Quite surprisingly, the same mathematics applies to the situation, and many of the same strategies apply: just-in-time, pull, continuous flow and so on.

I will need one entire column to describe the application of lean manufacturing to project management. In the meantime, other people have written quite a lot on this topic [5, 6]. In the next columns in this mini-series, I will develop these ideas more, and show how they drive project management, whether agile, adaptive, neither or both.

[1] Brown, N., “Disciplines Delivering Success,”STC 1997.

[2] Cockburn, A., “The End of Software Engineering and the Start of Economic Cooperative Gaming”

[3]Cockburn, A., “What the Agile Toolbox Contains,” online at http://www.stsc.hill.af.mil/crossTalk/2004/11/0411Cockburn.html

[4] Cockburn, A., “Information Radiators”, online at http://alistair.cockburn.us/index.php/Information_radiator

[5] David Anderson’s site: http://www.agilemanagement.net/

[6] Mary and Tom Poppendieck’s site: http://www.poppendieck.com/publications.htm

Dr. Alistair Cockburn was named one of “The All-Time Top 150 i-Technology Heroes” in 2007. He is an internationally renowned project witchdoctor and IT strategist, best known for co-authoring the Manifesto for Agile Software Development and articulating how to write effective use cases. His specialties are organizational redesign and project management strategies using agile and lean principles. You might enjoy getting pleasantly lost among his many articles and talks posted at http://Alistair.Cockburn.us. http://www.gantthead.com/content/articles/

[gallery]

Aligning Project Workforce with Business and Project Objectives

Format: Evaluation Form

Contributed by: Joe Wynne

Get your project team--and every project team in your organization--aligned with the overall business strategy to really improve perfomance and your company's bottom line. This template, designed as part of a complete employee motivation and retention strategy, will help you organize information on your business objectives and precisely how your project and each team member and task works toward meeting those defined objectives.

Purpose

This template is designed to assist a project manager with improving project workforce performance by aligning worker efforts and project objectives to business objectives and strategic initiatives. This alignment is part of a proven employee motivation and retention strategy.

When to Use

Complete During Planning Stage

Use information when preparing for Kick-off Meeting (Activation Stage) and for continuing communications

Disseminate to team leads and managers to ensure consistent communication and implementation

Review & revise after significant organizational change

Business objectives and/or strategic initiatives that this project supports:

Precisely how this project supports the above (be concise)

Project requirements and how they link to meeting goals and initiatives above (scheduling, budget, quality, customer satisfaction, organizational effectiveness, etc.)

How each project worker role contributes to meeting project requirements. (List each major role with short description of contribution.) · ·

How workers will be supported to attain any additional skills needed to meet project and business objectives

How workers will be able to find out how well they are meeting project and business goals (include all methods of feedback)

How project workers are to escalate problems that interfere with meeting project or business goals