Please specify the group
Archive | 2012

MongoDB – Introduction


MongoDB wasn’t designed in a lab. We built MongoDB from our own experiences building large scale, high availability, robust systems. We didn’t start from scratch, we really tried to figure out what was broken, and tackle that. So the way I think about MongoDB is that if you take MySql, and change the data model from relational to document based, you get a lot of great features: embedded docs for speed, manageability, agile development with schema-less databases, easier horizontal scalability because joins aren’t as important. There are lots of things that work great in relational databases: indexes, dynamic queries and updates to name a few, and we haven’t changed much there. For example, the way you design your indexes in MongoDB should be exactly the way you do it in MySql or Oracle, you just have the option of indexing an embedded field.
– Eliot Horowitz, 10gen CTO and Co-founder

Why MongoDB?

•Documents (objects) map nicely to programming language data types
•Embedded documents and arrays reduce need for joins
•Dynamically-typed (schemaless) for easy schema evolution
•No joins and no multi-document transactions for high performance and easy scalability
•High performance
•No joins and embedding makes reads and writes fast
•Indexes including indexing of keys from embedded documents and arrays
•Optional streaming writes (no acknowledgements)
•High availability
•Replicated servers with automatic master failover
•Easy scalability
•Automatic sharding (auto-partitioning of data across servers)
•Reads and writes are distributed over shards
•No joins or multi-document transactions make distributed queries easy and fast
•Eventually-consistent reads can be distributed over replicated servers
•Rich query language

Large MongoDB deployment

1. One or more shards, each shard holds a portion of the total data (managed automatically). Reads and writes are automatically routed to the appropriate shard(s). Each shard is backed by a replica set – which just holds the data for that shard.
A replica set is one or more servers, each holding copies of the same data. At any given time one is primary and the rest are secondaries. If the primary goes down one of the secondaries takes over automatically as primary. All writes and consistent reads go to the primary, and all eventually consistent reads are distributed amongst all the secondaries.
2. Multiple config servers, each one holds a copy of the meta data indicating which data lives on which shard.
3. One or more routers, each one acts as a server for one or more clients. Clients issue queries/updates to a router and the router routes them to the appropriate shard while consulting the config servers.
4. One or more clients, each one is (part of) the user’s application and issues commands to a router via the mongo client library (driver) for its language.
mongod is the server program (data or config). mongos is the router program.

Small deployment (no partitioning)
1. One replica set (automatic failover), or one server with zero or more slaves (no automatic failover).
2. One or more clients issuing commands to the replica set as a whole or the single master (the driver will manage which server in the replica set to send to).

Mongo data model
•A Mongo system (see deployment above) holds a set of databases
•A database holds a set of collections
•A collection holds a set of documents
•A document is a set of fields
•A field is a key-value pair
•A key is a name (string)
•A value is a
•basic type like string, integer, float, timestamp, binary, etc.,
•a document, or
•an array of values

Mongo query language
To retrieve certain documents from a db collection, you supply a query document containing the fields the desired documents should match. For example, {name: {first: ‘John’, last: ‘Doe’}} will match all documents in the collection with name of John Doe. Likewise, {name.last: ‘Doe’} will match all documents with last name of Doe. Also, {name.last: /^D/} will match all documents with last name starting with ‘D’ (regular expression match).
Queries will also match inside embedded arrays. For example, {keywords: ‘storage’} will match all documents with ‘storage’ in its keywords array. Likewise, {keywords: {$in: [‘storage’, ‘DBMS’]}} will match all documents with ‘storage’ or ‘DBMS’ in its keywords array.
If you have lots of documents in a collection and you want to make a query fast then build an index for that query. For example, ensureIndex({name.last: 1}) or ensureIndex({keywords: 1}). Note, indexes occupy space and slow down updates a bit, so use them only when the tradeoff is worth it.

Leave a comment Continue Reading →

Change Management

The relationship between project management, Managing Successful Programs (MSP) and change management is not clearly defined. You need the former two to run smoothly for the majority of the time, and for them both to be able to be adapted in times of change

For a company to overhaul its systems, individual projects need to be moved across, along with a set of more long-term programs. Having staff with training in Project Management, Managing Successful Programs and, distinctly, Change Management is necessary for all business areas.

Change management specialists are hoping that the coming years will see an increase in recognition for what they can offer businesses. Here are some areas in which they can push forward in achieving this.

  1. Organizational Buy-In Executives and business owners are now more aware than ever of how change management techniques can be used to benefit their companies. However, there’s still a long way to go for this to be true across the board.

    It will be up to the change management profession to push for this buy-in by displaying professionalism and really delivering results.

  2. Build Relationships

    The links between Project Managers, Program Managers and Change Mangers are very tight, and need to be nurtured for the long-term success of any of the three. Rather than working against each other for recognition, the three professions need to work together and display how they are together indispensable for business today.

  3. Remember Both Projects and Programs

    When change occurs, both short-term projects and permanent programs will need to move with the times. Focusing on one at the expense of the other will be of detriment to your success in change management.

  4. Emphasize Differences

    Many companies assume their program or project managers will act as change managers when the time comes – when in fact a different set of skills is needed. Other organizations take the opposite stance of only employing certified change managers. Make sure you’re affiliated with bodies such as the Change Management Institute and the Association of Change Management Professionals in order to ensure the right standards are set.

  5. Keep an Eye on your Soft Skills

    Change managers, like project managers, need to be able to communicate, motivate and manage people through times of progress and change. Many change managers will be hired on their track record of getting results – but will be hired back if they can get these results whilst being personable and professional.

Leave a comment Continue Reading →

Project Risk Management

Risk Management is the process of identifying, analyzing and responding to risk factors throughout the life of a project in order to provide a rational basis for decision making in regards to all risks. Proper risk management implies the control of possible future events, and is proactive rather than reactive; so it is embedded in to the project planning process. It will reduce not only the likelihood of an event occurring, but also the magnitude of its impact.

Importance of Project Risk Management

Projects often get started in the right direction but then get off track. For example, project managers will spend time with their teams to develop a clear scope and detailed plan. Then something happens; something unexpected—a major disaster strikes. The project manager and team move quickly into their reactive mode – they manage this risk based on their experiences and best judgment but they have no opportunity to test it out and they hope that it’ll be okay, but they do not know for sure. This is not risk management – it is management by crisis. Here are some rules to help you manage project risk effectively:

10 Rules for Managing Project Risk

The Risk Management Process is intended to reduce management by crisis. While there may always be some things that will occur that are unanticipated, most of these, through sound risk management, can be managed, rather than reacted to. Essentially, the Risk Management Process is a quality problem- solving process. Quality and assessment tools are used to determine and prioritize risks for assessment.

  1. Identify the risks early on in your project  
    • Review the lists of possible risk sources as well as the project team’s experiences and knowledge.  
    • Brainstorm all potential risks.
    • Brainstorm all missed opportunities if project is not completed.
    • Make clear who is responsible for what risk.
  2. Communicate about risks
    • Pay attention to risk communication and solicit input at team meetings to ensure that risk management is perceived as important for the project.  
    • Focus your communication efforts with the project sponsor or principal on the big risks and make sure you don’t surprise the boss or the customer.
    • Also, make sure that the sponsor makes decisions on the top risks, because some of them usually exceed the mandate of the project manager.
  3. Consider opportunities as well as threats
    • While risks often have a negative connotation of being harmful to projects, there are also “opportunities” or positive risks that may be highly beneficial to your project and organization. Make sure you create time to deal with the opportunities in your project. Chances are your team will identify a couple of opportunities with a high pay-off that may not require a big investment in time or resources. These will make your project faster, better and more profitable.
  4. Prioritize the risks
    • Some risks have a higher impact and probability than others. Therefore, spend time on the risks that cause the biggest losses and gains. To do so, create or use an evaluation instrument to categorize and prioritize risks.  
    • The number of risks identified usually exceeds the time capacity of the project team to analyze and develop contingencies. The process of prioritization helps the project team to manage those risks that have both a high impact and a high probability of occurrence.
  5. Assess the risks
    • Traditional problem solving often moves from problem identification to problem solution. However, before trying to determine how best to manage risks, the project team must identify the root causes of the identified risks.  
    • Risk occurs at different levels. If you want to understand a risk at an individual level, think about the effect that it has and the causes that can make it happen. The project team will want to ask questions including:
      • What would cause each risk?  
      • How will each risk impact the project? (i.e., costs? lead time? product quality? total project?)
    • The information you gather in a risk analysis will provide valuable insights in your project and the necessary input to find effective responses to optimize the risks.
  6. Develop responses to the risks
    • Completing a risk response plan adds value to your project because you prevent a threat occurring or minimize the negative effects. To complete an assessment of each risk you will need to identify:  
      • What can be done to reduce the likelihood of each risk?  
      • What can be done to manage each risk, should it occur?
      • What can be done to ensure opportunities are not missed?
  7. Develop the preventative measure tasks for each risk
    • It’s time to think about how to prevent a risk from occurring or reducing the likelihood for it to occur. To do this, convert into tasks, those ideas that were identified to reduce or eliminate risk likelihood.
  8. Develop the contingency plan for each risk
    • Should a risk occur, it’s important to have a contingency plan ready. Therefore, should the risk occur, these plans can be quickly put into action, thereby reducing the need to manage the risk by crisis.
  9. Register project risks
    • Maintaining a risk log enables you to view progress and make sure that you won’t forget a risk or two. It’s also a communication tool to inform both your team members, as well as stakeholders, what is going on. 
    • If you record project risks and the effective responses you have implemented, you create a track record that no one can deny, even if a risk happens that derails the project.
  10. Track risks and associated tasks
    • Tracking tasks is a day-to-day job for each project manager. Integrating risk tasks into that daily routine is the easiest solution. Risk tasks may be carried out to identify or analyze risks or to generate, select and implement responses. The daily effort of integrating risk tasks keeps your project focused on the current situation of risks and helps you stay on top of their relative importance.


The benefit of risk management in projects is huge because the outcome of project failure is wasted dollars that steal investor profits and have a negative impact on the organization’s bottom-line. Risk assessments allow you to deal with uncertain project events in a proactive manner. This allows you to deliver your project on time, on budget and with quality results.

Complete your risk assessment early on in the project’s execution and continuously (i.e.; every 2 to 3 months), throughout the project’s lifecycle. This will increase your project’s success likelihood. And, whenever possible, measure the effects of your risk management efforts and continuously implement improvements to make it even better.


Leave a comment Continue Reading →

Effective Communication

All happy families resemble one another, each unhappy family is unhappy in its own way.” Thus begins Leo Tolstoy’s  epic Anna Karenina. What he meant, perhaps, is that communication is complete when the mind is happy and uninhibited, and distortion creeps in when the mood is sullen and sad. Most problems in an organization, family or group are the result of people failing to communicate. Haven’t you often said “You don’t understand what I say” or words to that effect? Communication is the exchange or flow of information and ideas between one person and another. Technically, it involves a sender passing on an idea to a receiver. Effective communication occurs when the receiver comprehends the information or idea that the sender intends to convey.

What does a communication process involve? You have an idea that you need to communicate, and a message is sent to the receiver, either verbally or non-verbally. The receiver then translates the words or nonverbal gestures into a concept or information. Let’s take, for example, this message: “You are very intelligent.” Would this message carry the same meaning to the receiver every time you voice these words?

The success of the transmission depends on two factors—content and context. Content is the actual words or symbols that constitutes a part of the message, known as language. It could be either spoken or written. We all interpret words in our own ways, so much so that even simple messages could be understood differently.

Context is the way the message is delivered-the tone, expression in the sender’s eyes, body language, hand gestures, and state of emotion (anger, fear, uncertainty, confidence and so on). As we believe what we see more than what we hear, we trust the accuracy of nonverbal behavior more than verbal behavior. So when we communicate, the other person notices two things: What we say and how we say it.

Normally we think communication is complete once we have conveyed the message: “I don’t know why it was not done. I had asked him to do it.” Chances are that the message was not perceived properly. A message hasn’t been communicated successfully unless the receiver understands it completely. How do you know it has been properly received? By two-way communication or feedback.


Ourselves: Focusing on ourselves, rather than the other person can lead to confusion and conflict. Often, we are thinking about our response, rather than focusing on what the other person is saying. Some other factors that cause this are defensiveness (we feel someone is attacking us), superiority (we feel we know more than the other), and ego (we feel we are the center of the activity).

Perception: If we feel the person is talking too fast, not fluently or does not articulate clearly, we may dismiss the person. Our preconceived attitudes affect our ability to listen. We listen uncritically to persons of high status and dismiss those of low status.

Mental state: People don’t see things the same way when under stress. What we see and believe at a given moment is influenced by our psychological frames of references-beliefs, values, knowledge, experiences and goals.

These barriers are filters that we use to decide what is useful for us. No one can completely avoid these filters. If you start taking every information and message you get seriously, you would be overloaded with information. But if you are not consciously aware of this filtering process, you may lose a lot of valuable information. A way to overcome these filters when you want is through active listening and feedback.


All of us can hear, but all of us cannot listen. Hearing and listening are not the same thing. Hearing is involuntary and listening involves the reception and interpretation of what is heard. It decodes the sound heard into meaning. Does a knock on the door sound the same all the time? What if you are alone and you hear a knock at late night? What happens when you hear a knock while you are expecting someone whom you like?

People generally speak at 100 to 175 words per minute but we can listen intelligently at 600 to 800 words per minute. This means most of the time only a part of our mind is paying attention, it is easy for the attention to drift. This happens to all of us. The cure: active listening. This involves listening with a purpose. It may be to gain information, obtain directions, understand others, solve problems, share interests, see how the other person feels, even show support. This type of listening takes the same amount of or more energy than speaking. This requires the listener to hear various messages, understand the meaning and then verify the meaning by offering feedback. Here are some of the traits of an active listener:

• Does not finish the sentence of others.
• Does not answer questions with questions.
• Is aware of biases. We all have them… we need to control them.
• Never daydreams or becomes preoccupied with one’s own thoughts when others talk.
• Lets others talk.
• Does not dominate the conversation.
• Plans responses after the other persons have finished speaking, not while they are speaking.
• Provides feedback, but does not interrupt incessantly.
• Analyses by looking at all the relevant factors and asking open-ended questions.
• Keeps the conversation on what the speaker says…not on what interests them.
• Takes brief notes. This forces one to concentrate on what is being said.

Leave a comment Continue Reading →

Java Coffee Break – Java revolutionary language

Java – an island of Indonesia, a type of coffee, and a programming language. Three very different meanings, each in varying degrees of importance. Most programmers, though, are interested in the Java programming language. In just a few short years (since late 1995), Java has taken the software community by storm. Its phenomenal success has made Java the fastest growing programming language ever. There’s plenty of hype about Java, and what it can do. Many programmers, and end-users, are confused about exactly what it is, and what Java offers.

Java is a revolutionary language

The properties that make Java so attractive are present in other programming languages. Many languages are ideally suited for certain types of applications, even more so than Java. But Java brings all these properties together, in one language. This is a revolutionary jump forward for the software industry.

Let’s look at some of the properties in more detail: –

  • object-oriented

  • portable

  • multi-threaded

  • automatic garbage collection

  • secure

  • network and “Internet” aware

  • simplicity and ease-of-use


Many older languages, like C and Pascal, were procedural languages. Procedures (also called functions) were blocks of code that were part of a module or application. Procedures passed parameters (primitive data types like integers, characters, strings, and floating point numbers). Code was treated separately to data. You had to pass around data structures, and procedures could easily modify their contents. This was a source of problems, as parts of a program could have unforeseen effects in other parts. Tracking down which procedure was at fault wasted a great deal of time and effort, particularly with large programs.

In some procedural language, you could even obtain the memory location of a data structure. Armed with this location, you could read and write to the data at a later time, or accidentally overwrite the contents.

Java is an object-oriented language. An object-oriented language deals with objects. Objects contain both data (member variables) and code (methods). Each object belongs to a particular class, which is a blueprint describing the member variables and methods an object offers. In Java, almost every variable is an object of some type or another – even strings. Object-oriented programming requires a different way of thinking, but is a better way to design software than procedural programming.

There are many popular object-oriented languages available today. Some like Smalltalk and Java are designed from the beginning to be object-oriented. Others, like C++, are partially object-oriented, and partially procedural. In C++, you can still overwrite the contents of data structures and objects, causing the application to crash. Thankfully, Java prohibits direct access to memory contents, leading to a more robust system.


Most programming languages are designed for a specific operating system and processor architecture. When source code (the instructions that make up a program) are compiled, it is converted to machine code which can be executed only on one type of machine. This process produces native code, which is extremely fast.

Another type of language is one that is interpreted. Interpreted code is read by a software application (the interpreter), which performs the specified actions. Interpreted code often doesn’t need to be compiled – it is translated as it is run. For this reason, interpreted code is quite slow, but often portable across different operating systems and processor architectures.

Java takes the best of both techniques. Java code is compiled into a platform-neutral machine code, which is called Java bytecode. A special type of interpreter, known as a Java Virtual Machine (JVM), reads the bytecode, and processes it. Figure One shows a disassembly of a small Java application. The bytecode, indicated by the arrow, is represented in text form here, but when compiled it is represented as bytes to conserve space.

Figure One – Bytecode disassembly for “HelloWorld”

The approach Java takes offers some big advantages over other interpreted languages. Firstly, the source code is protected from view and modification – only the bytecode needs to be made available to users. Secondly, security mechanisms can scan bytecode for signs of modification or harmful code, complimenting the other security mechanisms of Java. Most of all though, it means that Java code can be compiled once, and run on any machine and operating system combination that supports a Java Virtual Machine (JVM). Java can run on Unix, Windows, Macintosh, and even the Palm Pilot. Java can even run inside a web browser, or a web server. Being portable means that the application only has to be written once – and can then execute on a wider range of machines. This saves a lot of time, and money.


If you’ve ever written complex applications in C, or PERL, you’ll probably have come across the concept of multiple processes before. An application can split itself into separate copies, which run concurrently. Each copy replicates code and data, resulting in increased memory consumption. Getting the copies to talk together can be complex, and frustrating. Creating each process involves a call to the operating system, which consumes extra CPU time as well.

A better model is to use multiple threads of execution, referred to as threads for short. Threads can share data and code, making it easier to share data between thread instances. They also use less memory and CPU overhead. Some languages, like C++, have support for threads, but they are complex to use. Java has support for multiple threads of execution built right into the language. Threads require a different way of thinking, but can be understood very quickly. Thread support in Java is very simple to use, and the use of threads in applications and applets is quite commonplace.

Automatic garbage collection

No, we’re not talking about taking out the trash (though a computer that could literally do that would be kind of neat). The term garbage collection refers to the reclamation of unused memory space. When applications create objects, the JVM allocates memory space for their storage. When the object is no longer needed (no reference to the object exists), the memory space can be reclaimed for later use. 

Languages like C++ force programmers to allocate and deallocate memory for data and objects manually. This adds extra complexity, but also causes another problem – memory leaks. When programmers forget to deallocate memory, the amount of free memory available is decreased. Programs that frequently create and destroy objects may eventually find that there is no memory left. In Java, the programmer is free from such worries, as the JVM will perform automatic garbage collection of objects.


Security is a big issue with Java. Since Java applets are downloaded remotely, and executed in a browser, security is of great concern. We wouldn’t want applets reading our personal documents, deleting files, or causing mischief. At the API level, there are strong security restrictions on file and network access for applets, as well as support for digital signatures to verify the integrity of downloaded code. At the bytecode level, checks are made for obvious hacks, such as stack manipulation or invalid bytecode. The strong security mechanisms in Java help to protect against inadvertent or intentional security violations, but it is important to remember that no system is perfect. The weakest link in the chain is the Java Virtual Machine on which it is run – a JVM with known security weaknesses can be prone to attack. It is also worth noting that while there have been a few identified weaknesses in JVMs, they are rare, and usually fixed quickly. 

Network and “Internet” aware

Java was designed to be “Internet” aware, and to support network programming. The Java API provides extensive network support, from sockets and IP addresses, to URLs and HTTP. It’s extremely easy to write network applications in Java, and the code is completely portable between platforms. In languages like C/C++, the networking code must be re-written for different operating systems, and is usually more complex. The networking support of Java saves a lot of time, and effort.

Java also includes support for more exotic network programming, such as remote-method invocation (RMI), CORBA and Jini. These distributed systems technologies make Java an attractive choice for large distributed systems.

Simplicity and ease-of-use

Java draws its roots from the C++ language. C++ is widely used, and very popular. Yet it is regarded as a complex language, with features like multiple-inheritance, templates and pointers that are counter-productive. Java, on the other hand, is closer to a “pure” object-oriented language. Access to memory pointers is removed, and object-references are used instead. Support for multiple-inheritance has been removed, which lends itself to clearer and simpler class designs. The I/O and network library is very easy to use, and the Java API provides developers with lots of time-saving code (such as networking and data-structures).  After using Java for awhile, most developers are reluctant to return to other languages, because of the simplicity and elegance of Java.


Java provides developers with many advantages. While most of these are present in other languages, Java combines all of these together into one language. The rapid growth of Java has been nothing short of phenomenal, and shows no signs (yet!) of slowing down.

Leave a comment Continue Reading →

The Assertive Leader

People can often use the word ‘assertive’ as a polite way of describing a person who exhibits aggressive behavior. This is understandable as the label of ‘aggressive’ is not something that we like to give to others. For example, it’s not uncommon to hear people say things like”… just be careful of Bryan, he’s… very assertive.” Well the truth is that if you have to be careful of Bryan it’s because he’s aggressive, not because of his assertiveness.

I make this point at the outset, because over the years of training people in advanced communication and leadership skills, it has become apparent that people often have a genuine misconception of what it means to be assertive. The best way to explain assertiveness is to put it in the context of both aggressiveness and submissiveness.

There are three distinct styles of relationships that we can choose to have;

  • Aggressive – Seeking to get your own needs met and rights honored at the expense of or without consideration for the other person’s needs and rights.
  • Submissive – The exact opposite of aggressive. Allowing the other person to get their needs/rights met at the expense of yours
  • Assertive – Seeking to get your needs/rights met in a way that doesn’t block the other person from meetings their needs and rights.

Assertiveness is non-judgmental, non-blameful and ensures that the relationship is maintained if not strengthened. Yes assertiveness is hard work.

Assertive skills are almost always part of any capability leadership framework for leadership development. To be assertive the leader must firstly know what their purpose is and what their needs are. Sometimes leaders neglect to realize that the organizations needs become their own needs – since they will be held accountable for meeting organizational goals and implementing policy and procedure.

To be assertive the leader needs to appropriately tell others about their thoughts and feelings and initiate action to get their needs met. As such, communicating and acting directly and honestly is essential to being effectively assertive. The key skill in communicating assertively is the effective use of “I” Messages.

“l-Messages” are very different from messages that contain a “You” component such as these:

  • “You stop it!”
  • “If you don’t stop, then… “
  • “What you should do is… “
  • “You need to… “
  • “You have to… or… “
  • “Why don’t you try this?”
  • “You are thoughtless!”
  • “You are just showing off.”
  • “Why would you do that!?”

The “You” part of these messages is likely to cause the receiver to interpret these messages as a judgmental, threatening or interfering. This is unlikely to influence the person to change. In fact it can cause the receiver to resist change more then before. Further to this it can escalate conflicts instead of helping to effectively manage them. You messages are risky, particularly in emotionally charged situations. They tend to have these unfortunate effects;

  • They make people feel guilty
  • People feel criticized, blamed or ‘put-down’
  • They often incite retaliation from the receiver
  • They can reduce a person’s self-esteem
  • They cause resistance to change
  • They may make people feel hurt, embarrassed

“You Messages” are not only damaging to relationships but they are actually very inaccurate messages. You messages come from our own paradigm, not that of the other person. When someone’s behavior is unacceptable to you, it is because it makes you worried, upset, disappointed, afraid, needful, or negatively affected in some other way – these feelings come from your own paradigm… and you own the problem. Therefore the most authentic and integral way of communicating your thoughts and feelings is with I Messages, or what I call “Authentic Messages” such as…

  • “I’m worried about… “
  • “I am upset… “
  • “I need your help with… because… “
  • “I will miss my deadline… “
  • “I will have to pay more… “
  • “I will have to put in more time… “
  • “I will lose sales… “
  • “I am disappointed… “
  • “I need more time… “
1 Comment Continue Reading →

Agile Awareness – opportunity for North India Chapter Members Only

Here is another opportunity for PMI North India Chapter to volunteer and contribute to community growth by participating in the following opportunities (PDU’s will also be awarded)

PMI India is planning a session on Agile awareness for a leading MNC, who is world’s leading provider of integrated mail and document management systems, services and solutions with multibillion dollar turnover.  The session is being planned to be organized sometime in July 2012, date for which will be finalized once the volunteers are shortlisted and vetted with the client. Requirement details for the volunteering opportunity are as under:


Session Details –


Date –                   July 2012

Session –             1 ½ hour (30 mins Q&A included)

Audience Profile

1.       Nos of PM’s – 15 to 20 approximately

2.       Exp – between 3 to 10 years

Topics –            Agile Awareness

Objective –        Value of Agile to business


North India Chapter is looking at working with folks from the chapter who are preferably ACP certified besides folks who have worked for last 1-2 years or above on Agile Project Management. You are requested to revert with your resumes to

1 Comment Continue Reading →