The artifacts* of software development projects are important intermediate deliverables during the SDLC (Software Development Lifecycle). Example artifacts include project plans, requirements documents, user stories, data models, designs, etc.
Although such artifacts have value, they are not an end in and of themselves. That is to say, it’s not their existence that is important but the quality of the thinking and communication that led to their existence. Also, it is how they are utilised once they exist that is important.
I have seen situations where the mere existence of a project plan for example, makes the stakeholders happy. “The Project Manager has a plan, I’ve seen it with my own eyes, therefore we are in good shape!”. Clearly, it is the quality of the plan and how that plan is executed that is the real measure of project health. It is the strategy that underpins that plan. Likewise, the very existence of a completed requirements document does not tell you how much quality thinking and communication went into its making nor does it tell you how well the development team will honour those requirements in code.
So here’s a message to anyone collaborating on a software development project or anyone managing such an endeavour: Look beyond the mere existence of artifacts and examine their quality, question the means by which they were created and how they will be used to deliver real value.
* I am using the American spelling here as this is the one most often encountered in geek literature.