1 Step To Better SharePoint Project Management – Say No

There is one aspect that I unswervingly observe about project managers in relation to their project success rate, even though habitually my project management observations firmly occur from the SharePoint side. It seems without disappointment that the cumulative number of successful projects that a PM owns correlates with the maturity of their ability to elegantly push clients back from making decisions that appear to be unhealthy. In other words, they can look a client in the face, and while saying yeah….that’s actually bullshit and we’re not going to do it, appropriately spin a “no” response so that it doesn’t emerge so negative. In fact, they can get a client downright excited to get turned down for a feature that’s bubbled up, basically acknowledging that the client requirement makes sense, hell it’s a great idea, but it increases risk and costs right now. Coupling with this distinct skill is that these types of project managers often times can also step back from a client given requirement, and gauge what would be the most apposite response, regardless of the size of the decision. While at first glance the cost of immediately accepting such a poor input from the client is not instantaneously evident (since it is somewhat masked by the requirements timeline) even smaller decisions when coupled together can swiftly disassemble what otherwise can prove to be a successful project.

The incapacity to say no can without difficulty produce chaos with any type of project regardless of industry and target; however it is extremely prevalent to see it within software development projects. More specifically, with SharePoint projects (since project management on SharePoint will often, like several software products, mutate into some type of Software Product Strategy [SPS]). The grounds that scope creep and requirements overflow is so ordinary with collaboration systems is because its very nature is to touch and enable so many information workers. Once people get a taste of the functionality that you are offering them, the recommendations start to come in on how to enhance the system. The recommendations might get the right management ear, and then they become requirements, which tend to be out of the original project scope. Since internal customer management might not be technically experienced or not required to be for their job role, it is often difficult for them to put a filter in place which would otherwise sieve through those requirements. Following, those requirements are characteristically shot gunned at the consultants.

I am guilty of this as well; it’s not just an internal problem from the client. I often will bring additions that I am certain will greatly benefit the entire SharePoint environment. As a good SharePoint project manager though, while one should recognize that I might have good ideas for the platform, focusing on meeting the basic requirements is what at the end of the day pays the bills.

I am in no way proposing that for each requirement that comes down the pipeline that it should be immediately rejected. That would hinder and constrain the overall project deliverables, while making you appear to be rigid to both the client and your internal project team. I have however known, and worked for, companies in the past that handled requirements as they came down with instantaneous dismissal since it is admittedly the safest route to take. On the other end of the coin, you have requirements fanatics, which I tend to hate to work with even more than the former zealots. These personalities become aware of a requirement and it becomes holy doctrine for the rest of the team, they tend to be too god damn excited on delivering such random, unmeasured features to the client. Their passion for developing components for the customer is often times dampened with failure that ensues due to their mismanagement of basic organizational tasks when they become too overwhelmed with out of context actions.

Some of the reasons that a project manager, in the context of SharePoint, should say no is:

1) While this feature will extend our SharePoint environment, it is more of a nice-to-have, and not really a baseline requirement for this project

2) The calculated effort requirement by either/both the development or operations staff doesn’t really justify the production of the feature

3) The subproject in the terms of the current contract constraints doesn’t procure a practical baseline for reallocation (or allocation) of resources to make it a tangible production.

4) While this feature from the development or operations end is awesome, it is something that client doesn’t immediately realize the need for, or will never be noticed by the client

5) Holy crap, this doesn’t even qualify because it is so experimental, it isn’t funny (kind of like when a client asked me to build neural networks for forecasting models off SharePoint lists. Probably should have nixed that one).

So what to do? It’s all about promoting and maintaining a careful balance, supplemented with a project manager’s largest tool, a butt load of documentation. In this case, the particular piece of documentation that becomes your best friend is all that good stuff involved in the Change Control Process. I don’t mean go, download, and implement 50 templates that almost certainly include a bunch of fluff documents not required for your project. Each project is dissimilar, and since Change Control Processes while often times characterizing an orthodox set of documentation templates, doesn’t unavoidably mean it is all of a sudden project creed. The Change Control Process we must take into account is a supplement to a contract, placing both the client, as well as consultant, in a position to be subject to it. While it is inflexible in this regard, it ensures that requirements acknowledged and accounted for in the project plan are readily available to the client so that you can guarantee familiarity of current project state. Even while taking in the changes that may have come down the pipeline.

It is important that a project manager says no to a client, is all I am attempting to emphasize through this I suppose. This is particularly evident in SharePoint projects. While you shouldn’t say no to everything, the client is going to be partial to your organization a lot more when you completely relinquish a project with all the contracted features rather than delivering what is essentially a failed project with several half baked features.


CryptoCollaboration Version Alpha Released

Encryption while by all popular means with collaboration systems remains a somewhat esoteric subject, is nonetheless crucial for maintaining privacy, security, and data integrity. While the native SharePoint security functions do indeed provide some level of these concepts, it is limited in the sense that it is tailored around hiding items that you don’t have appropriate rights to, for most organizations this layer is simply not enough because the data still exists in a poolable format.

Typically industrial strength privacy collaboration environments generally instead require that an encryption solution be in place to couple appropriately with native security functions so as to ensure that the data itself remains unreadable to certain users. This is the purpose of CryptoCollaboration.

I have recently published the deployable project on CodePlex, at the following location:


It has already gone through one quick revision through the MVP group that gave me some good feedback regarding the interface and some brief functionality. If you want to see what the application itself looks like, you can view some brief screen shots on the CodePlex site.

Anyways, I feel like I have done enough typing about this project for the time being, so I will let the CodePlex site do the talking. If you have any suggestions, I would love to hear them. I am currently recording them on the issues list on CodePlex.


Introduction to Knowledge Management Within Collaboration Systems

What Is Knowledge Management?

KM is knowledge Management that works with arbitrary organizational systems, and it consists of human elements and processing. At one time, particular accomplishment issues restricted that KM elements be changeable, including restricting cost and general services. As advances took place however, the administrative of KM evolved with differentiating changes, while redefining doctrines of competing nature, changing the outlook of Knowledge Management. Today, the knowledge management atmosphere progresses by predicting documentable issues before they arrive and serving them to progress. Thus, the system works to manage the querying parties by instigating tactics and enforcing the action throughout the lifespan of the KM lifecycle. This approach does required substantial investments and intelligence assets. The key focus in the Knowledge Management-KM system within an arbitrary organization remains lagging the intellect of the organizational KM from deterioration.

Why Is Knowledge Management Important?

Many organizations lack knowledge of the usage of their achieved information bottom. The information is often left behind since employees’ abrasion causes deterioration, and the high rates of turnover, and cost-effective measures, including wrongfully submitted documentation, have brought down the insight and need for KM.

Certain tools in KM, such as metrics center on the organizational gain, storage, and retrieving of intelligent benefits. The focus is tangibly constructed with other tools to make the system work, including enhancing strategic for learning, planning and making decisions.

The concept lengthens the skills of logic, and productively designing plans in growth and development.

Knowledge Assets and Management Tools

The Knowledge Management-KM views the knowledge assets and management tool for gain. The improvement of organizational output directs toward the proportional assets of intellect. The skillfully KM tool promotes expertise, while promoting employees to stay focused while capturing the reflections of its strategy, practicing devices, policy scheme, and capturing the information at each level of the arbitrary job type and activity level.

The insubstantial benefit of KM to employees’ for fundamental novelty in that it goes forward in planning, interchanging in management, culture of the company, while giving a balance to an approach.

KM is vital for developing sharing of knowledge attitudes and competence in a multitude of job roles, regardless of industry.

Sharing is essential in managing the KM assets since it reduces or increases cost, ‘cycle time,’ and improves the overall investments, satisfaction, indexing, and leaves room for healthier intellect and and methods for intellectual storage.

Knowledge Management Spreading To Industries

At one time, KM was only available to a handfull of organization, or, rather leveraged to a successful point by a few. Over the past few years however, researchers exploded and brought forth new light and applications. A measure of concern in the strategy of KM is pending for few orgniazations, which poses a threat, since it may affect the reproduction of intelligence, entirety of excellence management, and the business of re-engineering. Discipline becomes an interest, since it must sustain at a particular level to remove any flaws from the concept simultaneously while delivering a measure of value to the business.

Ironically, however, as the disciplinary begins to work, interest of the concept is lost, and additional failures become apparent, thus, the true benefit is lost.

This leads to a breaking point, since ambitiously and interest of KM starting points in organizations evolves at various levels, and may work technically, but it will not continue working in an economical sense. With this in mind, we can see that the systems continue to be enormous gear for general employees will remain aware of the power and tools available to them over SharePoint.

The outlook is not completely unenthusiastic, even if it changes gradually from the first pattern.

Though substantial development has been reached, it will take extensive work to deliver KM promising value. In the end, in order to understand the true value of KM, industry experts must find motivation while including organization, sharing, and creating.